Phát hành Elixir 1.17: kiểu theo lý thuyết tập hợp cho pattern, Duration, OTP 27

 (elixir-lang.org)
1 điểm bởi GN⁺ 2024-06-13 | 1 bình luận | Chia sẻ qua WhatsApp
  • Kiểu theo lý thuyết tập hợp tiệm tiến suy luận kiểu từ pattern và đưa ra cảnh báo tại thời điểm biên dịch, bổ sung khả năng tìm lỗi và khiếm khuyết trong codebase mà không cần thay đổi phần mềm hiện có
  • Các cảnh báo kiểu mới hiện tập trung vào atom và map/struct, phát hiện pattern matching với khóa không tồn tại và truy cập field, gọi hàm không phải module, gọi hàm ẩn danh sai, so sánh cấu trúc giữa các struct, so sánh các kiểu không giao nhau, pattern binary không hợp lệ, rescue exception chưa được định nghĩa, v.v.
  • Type checker hiện chỉ suy luận kiểu từ các pattern trong cùng một hàm; phân tích guard và qua ranh giới hàm dự kiến sẽ được bổ sung trong các bản phát hành sau
  • Đã thêm hỗ trợ Erlang/OTP 27 và ngừng hỗ trợ Erlang/OTP 24; khuyến nghị di chuyển lên Erlang/OTP 26 trở lên, bao gồm cả trên Windows
  • Hỗ trợ WERL, giao diện đồ họa terminal Erlang cho Windows, dự kiến sẽ bị gỡ bỏ trong Elixir v1.18
  • Thêm kiểu dữ liệu Duration mới và Date.shift/2, cho phép dịch chuyển ngày, giờ và date time theo duration; trong DateTime, xử lý cả thay đổi múi giờ và Daylight Saving Time
  • Thêm Kernel.to_timeout/1, giúp chuẩn hóa duration và integer thành giá trị timeout dùng trong nhiều API như Process, GenServer, v.v.
  • Tính năng process label của Erlang/OTP 27 có thể được dùng trong Elixir qua Process.set_label/1; Logger định dạng báo cáo gen_statem và đưa process label của Erlang/OTP 27 vào các sự kiện logger
  • Thêm Keyword.intersect/2,3, profiler Mix mới mix profile.tprof, và guard Kernel.is_non_struct_map/1 để giảm bẫy trong đó %{} cũng match với struct
  • Cùng với việc thêm mix profile.tprof, mix profile.cprof và mix profile.eprof được đưa vào diện soft-deprecation

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-06-13
Ý kiến trên Hacker News

  • Trong vài năm gần đây, hệ sinh thái Elixir thực sự đang trở thành giải pháp đơn giản nhất cho rất nhiều mục đích
    Với Phoenix và LiveView, phát triển web vừa nhanh vừa thú vị; với NX/Axon/Bumblebee thì làm trí tuệ nhân tạo; với Membrane thì streaming và xử lý âm thanh/video; với Commanded thì CQRS và event sourcing; với Nerves thì chế tạo thiết bị nhúng; và với LiveView Native đang được phát triển thì thậm chí có thể làm cả ứng dụng di động
    Hàng đợi, pipeline và xử lý theo lô cũng có thể được xử lý phù hợp với từng nhu cầu bằng tính năng có sẵn hoặc GenStage, Broadway, Oban
    Dù vậy, cá nhân tôi thấy tính năng cốt lõi là IEx, REPL của Elixir. Việc có thể tương tác trực tiếp với code đang phát triển hoặc đang chạy production, nhìn vào bên trong và debug thật sự có thể thay đổi cuộc sống
    Việc bổ sung kiểu dữ liệu vào đây là mảnh ghép cuối cùng giúp chúng ta tự tin hơn nhiều vào code mình triển khai

    • Thêm vào đó, ExUnit giúp việc viết test trở nên cực kỳ dễ dàng, trình quản lý gói Hex thì cứ thế hoạt động tốt, còn FLAME cho phép mở rộng process sang máy tính khác gần như chỉ bằng một dòng code
      Ecto cho phép làm việc với cơ sở dữ liệu SQL theo phong cách hàm; tôi vẫn chưa biết nên nhìn nhận ORM thế nào, nhưng nếu chỉ với vài truy vấn có thể kết hợp mà loại bỏ được 90% SQL thì tôi xem đó là thành công
      Sau vài tháng vật lộn với triển khai, uptime, lỗi segmentation fault, thời gian xử lý package và những thứ tương tự, chúng tôi đã chuyển web server và tầng dữ liệu sang Elixir + Phoenix; giờ mọi thứ được test tốt hơn nhiều, dễ suy luận hơn, có khả năng mở rộng đáng tin cậy và triển khai cũng dễ hơn
      Nhờ quy ước thay vì cấu hình, có thể bắt đầu với Phoenix nhanh đến phi lý, còn nhanh hơn FastAPI rất nhiều. Tôi nghĩ lẽ ra mình nên làm việc này từ vài tháng trước
      Hiện giờ tôi đang huấn luyện model bằng Nx, thử nghịch Bumblebee/Livebook, và gần như miễn phí mà gắn được các tính năng presence và live vào ứng dụng
    • Quảng bá nhẹ cho LiveView Native thì nó không chỉ làm được ứng dụng di động, mà còn có thể làm cho desktop, đồng hồ, TV, Apple Vision Pro
      Tất cả đều dùng nguyên các khái niệm, hiệu năng và sự tiện lợi khi phát triển của LiveView
    • Từ góc nhìn của người đến từ các ngôn ngữ có hệ thống kiểu tĩnh mạnh mẽ và hữu ích, đây là khoảng trống đáng tiếc nhất, nên tôi đang tò mò theo dõi Gleam
      Có lẽ sẽ khó quay lại những nơi như Erlang hay Elixir
    • REPL của Elixir thuộc hàng đỉnh cao, và tôi đồng ý rằng đó là tính năng sát thủ thực sự của ngôn ngữ này
      Mỗi lần viết code bằng ngôn ngữ khác, đặc biệt là mỗi khi viết code để kiếm tiền, tôi đều rất nhớ nó
      Một REPL tốt giúp giảm đáng kể ma sát thường gặp trong lập trình. Thay vì chạy toàn bộ ứng dụng để chọc thử đoạn code có vấn đề, ta có thể xây dựng ý tưởng từng chút một và kiểm thử ngay tại chỗ
      Thư viện chuẩn của Elixir cũng rất tuyệt, việc truy cập tài liệu từ REPL cực kỳ dễ, nên giúp giữ được dòng suy nghĩ. Khi code bằng Elixir, tôi hiếm khi mở trình duyệt để tìm những câu hỏi nhỏ, vì thường có thể tìm được câu trả lời mà không cần rời REPL
      Vì thế nó cũng khuyến khích tôi viết docstring tốt cho code của mình
      Điểm hay hơn nữa là có thể chạy REPL cùng với code đang chạy. Ngay cả khi phải chạy ứng dụng, cứ để nó chạy như vậy, rồi trong môi trường phát triển có thể thao tác với dữ liệu live và quan sát trạng thái bên trong. Đây là việc bất khả thi ở các stack khác, hoặc phải cần đến debugger
      Giờ khi các tính năng liên quan đến type được đưa vào, tôi kỳ vọng công cụ sẽ còn tốt hơn nữa
      Thêm vào đó là sự thú vị và sức mạnh của paradigm lập trình hàm, cũng có những cách vững chắc để xử lý tính biến đổi và trạng thái, mà lại không phải chịu cú pháp LISP. Cá nhân tôi rất thích vì đây là ngôn ngữ chạm đúng mọi nốt nhạc với mình
    • Các ngôn ngữ khác chẳng phải cũng có nhiều thứ như vậy sao? Ruby có IRB
      IEx làm được điều gì mà IRB không có không?

  • Trong vài năm qua, đội ngũ Elixir và Erlang đã làm rất tốt, và cũng không thể bỏ qua công sức của các tác giả thư viện và sách
    Chưa bao giờ tôi mong chờ một bản phát hành như thế này. Tôi đã theo dõi các commit của Elixir và OTP một thời gian, và có cảm giác Elixir/Erlang rõ ràng đang có đà phát triển

  • Tôi đang dùng Elixir cho backend của side project, còn frontend là Remix; làm backend rất dễ chịu và năng suất
    Tôi công nhận năng suất của LiveView, nhưng trong trường hợp của tôi phải xử lý kết nối mạng không ổn định nên trải nghiệm LiveView đúng như dự đoán là không tốt
    Mong rằng trong đầu các lập trình viên, Elixir sẽ được tách khỏi LiveView ở một mức nào đó. Ngay cả khi chỉ dùng làm backend API đơn giản, không có LiveView hay kênh thời gian thực, Elixir vẫn thật sự rất thú vị

    • Tôi thật sự thích Elixir nên dùng cho hầu như mọi thứ, và LiveBook đã trở thành nơi mặc định để bắt đầu làm các phần mềm đồ chơi
      Nhưng LiveView thì tôi không làm tốt được. Nó khá khó hiểu và có nhiều cạm bẫy dưới chân. Ví dụ có trường hợp phải nhớ xử lý kiểm tra xác thực ở cả pipe_through của router lẫn callback on_mount của LiveView. Xem [0]
      Chỉ riêng việc câu trên hoàn toàn vô nghĩa với một lập trình viên mới tiếp cận Phoenix và LiveView cũng đã đủ là bằng chứng rằng LiveView không nên là cách mặc định
      Nó tạo ra một đường cong học tập rất dốc ở những nơi không cần thiết. Bản thân Elixir/Phoenix thì dễ
      Nếu là lập trình viên mới học Elixir/Phoenix, tôi cho rằng trình tự đúng là trước hết dùng Phoenix dead views theo kiểu MVC, rồi đọc “Elixir in Action” để học các nền tảng OTP. Cuốn sách này dễ đọc, mở mang tầm mắt và đã thay đổi gần như toàn bộ cách tôi lập trình
      Và chỉ sau đó mới nên chuyển sang LiveView
      [0]: https://hexdocs.pm/phoenix_live_view/security-model.html#liv...
    • Chạy mix phx.new với cờ —no-live thì có thể dùng Phoenix không có LiveView. Trong các dự án hiện có cũng có thể gỡ ra thủ công
    • Các câu trả lời cho đến giờ đang bỏ lỡ điểm chính
      Vấn đề không phải là kiến thức kỹ thuật hay mặc định khi cài đặt, mà là nhận thức của lập trình viên. Quá nhiều người nghĩ đến LiveView trước khi nghĩ đến Elixir và phần còn lại của hệ sinh thái, rồi bỏ qua các phần khác của hệ sinh thái
      Elixir rộng hơn thế rất nhiều, và ngay cả Phoenix cũng lớn hơn LiveView
      Hoàn toàn có thể xây dựng ứng dụng Elixir năng suất và hiệu quả về chi phí mà không cần LiveView, thậm chí không cần Phoenix. Việc chọn Elixir cho backend nên phổ biến hơn hiện nay, nhưng tôi cũng hiểu những định kiến và nỗi sợ khiến người ta chọn phương án khác

  • Tôi đang xây startup của mình theo hướng full-stack 100% Elixir, và đây là công nghệ tuyệt vời nhất tôi từng dùng cho đến nay
    Tôi liên tục truyền giáo cho những người bạn kỹ thuật nghiêm túc rằng nó tốt đến mức nào
    Giờ chỉ mong RabbitMQ và client của nó chạy được trên OTP 27. Tôi muốn nâng cấp

    • Tôi tò mò bạn đang làm gì mà cảm thấy Elixir đúng là nằm ở điểm phù hợp hơn các công nghệ khác
    • RabbitMQ khá vững chắc, bạn có gặp vấn đề kiểu rò rỉ hiệu năng không?
      Chúng tôi đã dùng cơ chế đăng nhập client bằng chứng chỉ SSL trong vài năm và rất hài lòng với độ ổn định

  • Nói tốt về Elixir và Phoenix bao nhiêu cũng không đủ. Khi có thêm kiểu nữa thì sẽ còn tốt hơn
    Bạn sẽ nghe nhiều về BEAM và sức mạnh của nó, nhưng theo kinh nghiệm, bạn có thể đi được rất xa trước khi phải nghĩ đến phần đó của stack. Phoenix trừu tượng hóa phần đó rất tốt, nên bạn nhận được lợi ích mà không cần nỗ lực
    Ví dụ có Oban. Bạn gần như miễn phí có được các tác vụ nền mạnh mẽ, linh hoạt và dễ dùng bằng code Elixir bên trong Postgres. Thật sự tuyệt vời
    Khuyên bạn nên thử

    • Nếu không có LiveView thì tôi đã hoàn toàn đồng ý
      Vì LiveView và sự ám ảnh marketing xung quanh nó, những người vốn có thể chưa cần biết OTP lâu hơn lại phải đối mặt với OTP từ rất sớm trong hành trình, có khi ngay từ route controller đầu tiên
      Việc viết và kiểm thử tốt một luồng LiveView chắc chắn phức tạp về mặt trí tuệ không kém việc viết một GenServer có trạng thái với nhiều luồng phi tuyến tính và nhiều điểm vào call/cast khác nhau
      LiveView dùng thuật ngữ khác và có một số lớp tiện ích nhỏ như async assigns, nhưng về mặt cơ chế thì đúng nghĩa là GenServer. Tôi nghĩ để dùng hiệu quả thì điều quan trọng là phải hiểu rõ điểm này
      Tôi thật sự thích Oban, và rất nhớ nó trong các hệ sinh thái khác

  • Nhân tiện, có ai đã dùng elixir-desktop [1] chưa? Nó là gói wxWidgets + LiveView nên khá giống ứng dụng Electron
    Ở [2], Wojtek Mach giải thích cách nhóm Elixir tạo Livebook Desktop. Nội dung nói về dự án bắt đầu như thế nào, các lỗi tinh vi phát hiện khi làm ứng dụng cho macOS, giới hạn của wxWidgets trên Windows và nhiều chi tiết triển khai
    Sẽ thật tốt nếu nhóm Elixir chính thức phát hành thứ gì đó như elixir-desktop dựa trên Livebook. Tức là fork kho Livebook và cung cấp một dự án template chính thức để tạo ứng dụng desktop dựa trên LiveView
    Hiện Livebook được phân phối dưới dạng file thực thi cho Windows và Mac. Nếu làm theo cùng cách để lập trình viên có thể phân phối file thực thi độc lập như Electron thì sao?
    Tôi cũng biết LiveView Native [3], nhưng nghĩ rằng hướng đi đó khác
    [1] https://github.com/elixir-desktop/desktop-example-app
    [2] https://www.youtube.com/watch?v=Kiw6eWKcQbg
    [3] https://native.live/

  • Tôi mong đến ngày cái cớ không có kiểu từng cản trở Elixir phổ biến sẽ biến mất

  • Trong suốt 10 năm qua tôi đã đọc những câu chuyện Elixir rất hay ở đây, và cũng thích ngôn ngữ này
    Nhưng tôi đã từ bỏ việc tìm việc Elixir từ vài năm trước. Vì lương dường như luôn thấp hơn các ngôn ngữ chủ đạo
    Có thể đó là ngôn ngữ tôi muốn dùng nhất, nhưng với tôi lương và một sản phẩm tuyệt vời quan trọng hơn tech stack, nên có lẽ thực tế tôi sẽ không làm được. Dù vậy, theo dõi từ xa vẫn rất thú vị

    • Với tư cách là lập trình viên Elixir, nghe nói lương thấp hơn các ngôn ngữ chủ đạo thì khá bất ngờ
      Không biết bạn đang tìm ở Mỹ hay khu vực khác?
    • Lương thường xuyên cao hơn các stack chủ đạo. Một phần là vì hầu hết các tin tuyển Elixir đều tìm kỹ sư senior

  • Tính năng hay trong bản phát hành này là việc bổ sung get_in/1 hoạt động cùng struct. Ví dụ có thể viết như get_in(struct.foo.bar)
    Nếu foo trả về nil thì khi truy cập bar sẽ không phát sinh ngoại lệ

    • Các phiên bản Elixir trước cũng làm được, nhưng cú pháp khá rườm rà
      Với các tầng không phải map thông thường thì cần Access.key như sau
      get_in(struct, [Access.key(:foo), :bar])

  • Đây là mảnh ghép cuối cùng mà tôi mong muốn. Tôi cũng kỳ vọng các bước tiếp theo
    Ngoài ra, theo tiêu chí của tôi thì ngôn ngữ này về mặt chức năng đã hoàn thiện 100%

    • Lần cuối tôi xem Elixir, có vẻ như mọi người đồng thuận rằng “cuối cùng thì cũng phải làm Erlang”
      Bây giờ vẫn vậy không, hay không còn cần phải xuống đến Erlang nữa?