Erlang/OTP 29.0

 (erlang.org)
1 điểm bởi GN⁺ 5 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • SSH daemon mặc định vô hiệu hóa các dịch vụ shell và exec, nên nếu không cấu hình rõ ràng thì người dùng đã xác thực sẽ không thể thực thi mã Erlang tùy ý
  • Khi khởi động SSH daemon, SFTP subsystem cũng không còn được bật mặc định, giúp tăng cường các giá trị mặc định về bảo mật
  • Thuộc tính -unsafe được bổ sung để đánh dấu các hàm không an toàn, và trình biên dịch mặc định tạo cảnh báo khi gọi các hàm mà Erlang/OTP luôn biết là không an toàn
  • xref có thể tìm các lời gọi hàm không an toàn và các hàm không có tài liệu, đồng thời việc lọc thuộc tính ignore_xref cũng được chuyển sang xử lý ngay trong xref
  • Trong cấu hình mặc định của SSL, x25519mlkem768 trở thành nhóm trao đổi khóa được ưu tiên cao nhất, và thuật toán trao đổi khóa mặc định của SSH cũng được đổi thành mlkem768x25519-sha256, kết hợp ML-KEM-768 và X25519
  • Trong đường dẫn mã mặc định của hệ thống Erlang, vị trí của thư mục làm việc hiện tại . được chuyển từ đầu xuống cuối, làm thay đổi thứ tự nạp
  • Bản dựng Erlang/OTP 32-bit cho Windows không còn được cung cấp
  • Native records của EEP-79 đã được triển khai và trong Erlang/OTP 29 được xem là tính năng thử nghiệm
  • Đã bổ sung guard BIF is_integer/3, comprehension đa giá trị dựa trên EEP 78, và cơ chế gán biến bên trong comprehension thông qua tính năng compr_assign
  • Trình biên dịch bổ sung cảnh báo mặc định cho catch, việc xuất biến ra ngoài biểu thức con, and/or, và các mẫu match alias như {a,B} = {X,Y}, đồng thời cung cấp tùy chọn tắt riêng cho từng loại
  • Các guard test cũ sẽ bị loại khỏi ngôn ngữ trong Erlang/OTP 30, và cảnh báo hiện có về việc dùng obsolete guard vẫn tiếp tục được áp dụng
  • Có thể dùng io_ansi để xuất ANSI/Virtual Terminal Sequence ra terminal, và dùng ct_doctest để kiểm thử các ví dụ trong tài liệu mô-đun Erlang và trong các tệp tài liệu

Bài viết liên quan

1 bình luận

 
GN⁺ 5 giờ trước
Ý kiến trên Hacker News

  • Các cải tiến trông khá ổn. Việc SSH daemon bị vô hiệu hóa mặc định và SFTP cũng bị vô hiệu hóa mặc định là thay đổi tốt về mặt bảo mật
    Module io_ansi cũng trông khá hay. Hiện tại Erlang chưa có nhiều câu chuyện thật sự nổi bật khi làm ứng dụng dòng lệnh phức tạp, nên nếu nó vào thư viện chuẩn thì có vẻ sẽ rất hữu ích về sau. Cách fwrite hoạt động tự nhiên giữa các node cũng đúng là kiểu ưu điểm người ta mong đợi ở Erlang
    Việc bổ sung Native Records cũng rất thú vị. Hiện tại trong Elixir có cảm giác record, tuple và map bị dùng lẫn tùy tình huống, nên khá tò mò xem sau này nó sẽ được tận dụng ra sao. Như EEP có nói, record hiện có sẽ không bị loại bỏ hoàn toàn, nhưng đây có vẻ là một cải tiến đáng kể
    https://www.erlang.org/doc/apps/ssh/ssh.html
    https://www.erlang.org/docs/29/apps/stdlib/io_ansi.html
    https://github.com/erlang/eep/pull/81

    • Tôi không nghĩ SSH daemon từng tự động được bật hay khởi động. Dù cách diễn đạt của hai mục khác nhau, ý nghĩa có vẻ là khi khởi động SSH daemon thì các thành phần được liệt kê sẽ không còn được khởi động mặc định nữa
      SSH daemon giờ đây mặc định tắt shell và dịch vụ exec, tuân theo nguyên tắc secure by default. Nếu không cấu hình rõ ràng thì người dùng đã xác thực sẽ không thể thực thi mã Erlang tùy ý
      Hệ thống con SFTP cũng không còn được bật mặc định khi khởi động SSH daemon nữa

  • Để giải thích cho ai thắc mắc OTP trong Erlang/OTP là gì, ban đầu đây là một bộ thư viện và nguyên tắc giúp chuẩn hóa cách xây dựng các ứng dụng độ tin cậy cao, chịu lỗi, dành cho lĩnh vực viễn thông
    Ý tưởng cốt lõi thì phần mở đầu của “OTP Design Principles” là một đoạn ngắn rất đáng đọc
    https://www.erlang.org/doc/system/design_principles.html

    • OTP = Open Telecom Platform

  • Nếu ứng dụng production của bạn vẫn đang dưới bản 29 thì có lẽ nên cập nhật càng sớm càng tốt lên bản này hoặc bản vá mới nhất. Tôi vừa triển khai lên production và hệ thống quét bảo mật tự động đã báo 2 CVE mức CRITICAL với ngày tháng 2~5/2026 cùng nhiều mục rủi ro HIGH

    • Có danh sách không?

  • Tôi vẫn tự hỏi còn ai dùng Erlang cho dự án mới nữa không
    Tôi biết ở đây có nhiều người thích Elixir, nhưng tôi đang nói đến Erlang thuần
    Nếu vẫn dùng Erlang, tôi tò mò vì sao bạn thích nó hơn Elixir

    • Năm nay thôi cũng đã có rồi. Có công việc IoT mới dựa trên AtomVM, một application server viết bằng Erlang, và một TUI framework vẫn đang làm dở
      Elixir không mang lại cho tôi lợi thế thực tế nào so với Erlang. Chắc chắn nó có thể có ưu điểm riêng, nhưng Erlang hợp với cách tôi suy nghĩ hơn. Tôi cũng muốn thử học hay tìm trợ giúp theo kiểu tụ tập cộng đồng, nhưng chưa tìm được chỗ nào thật sự hợp với mình

  • Có ai giải thích được nội bộ của nó không?

  • Khá tò mò xem record sẽ định vị thế nào trong hệ sinh thái

    • Tôi định nói “record đã có từ vài chục năm trước rồi mà?” nhưng rồi đọc changelog
      Khá thú vị. Tôi tự hỏi có khi nào sẽ có một thế giới mà Elixir biên dịch map thành native records không

  • Có ai biết WhatsApp vẫn còn dùng Erlang không?

    • Đúng vậy
      Họ đã dùng Erlang từ đầu những năm 2010, và vào khoảng đó giới công nghệ biết rằng WhatsApp có thể phục vụ hơn 400 triệu người dùng hoạt động chỉ với khoảng 30 kỹ sư
      Khi đó tôi đã liên hệ với một kỹ sư bên đó, và lúc còn sống ở Mỹ tôi đã nhận được email trả lời rất nhiệt tình cho vài câu hỏi. Cuối cùng còn đi uống cà phê nữa, và đến giờ vẫn giữ liên lạc
      Có thể nói Erlang vẫn là một phần quan trọng của WhatsApp
    • Nhìn vào bài trình bày ở Code BEAM Europe 2025 thì khả năng cao vẫn là vậy: https://www.youtube.com/watch?v=tC435RGwRCI
    • Tôi không biết trực tiếp, nhưng tôi rời đi vào năm 2019 và các kho Erlang công khai của WhatsApp vẫn còn hoạt động tích cực. Theo tôi biết thì Erlang cũng không lan ra toàn bộ Meta, nên nếu WhatsApp đã rời Erlang thì sau đó cũng không có nhiều lý do để tiếp tục làm việc về Erlang
    • Đúng vậy. Một nhân viên cũ của tôi hiện đang làm ở đó
    • Đúng vậy. Họ dùng Erlang và cũng đang tăng dần Rust

  • Có thêm hỗ trợ cho thuộc tính -unsafe, đúng là thời điểm hoàn hảo để viết lại bằng Rust /s

  • Tôi thật sự không hiểu ai dùng Erlang nữa. Tôi từng dùng Rails rồi thử Phoenix, và cảm thấy làm được việc gì đó khó hơn nhiều
    Tôi không hiểu nổi sự cuồng nhiệt dành cho Phoenix
    Với người phát triển một mình thì Rails có lẽ là hệ thống web app năng suất nhất. LLM cũng viết mã Ruby on Rails rất tốt. Dù tập dữ liệu huấn luyện Python lớn khủng khiếp, theo trải nghiệm của tôi thì nó vẫn viết tốt hơn Django rất nhiều
    Tôi viết app thử nghiệm bằng Rails, rồi khi ổn định thì viết lại bằng Go. Khi phạm vi ứng dụng còn chưa rõ mà lao ngay vào Go thì sẽ tốn token hơn rất nhiều, còn Rails thì cực kỳ hiệu quả
    Dạo này React hay Angular cũng không còn cần thiết nữa, với Rails thì tôi dùng Hotwire còn với Go thì dùng HTMX
    Ngay cả diễn đàn Erlang cũng dùng Discourse viết bằng Rails

    • Tôi đã viết ứng dụng Elixir toàn thời gian từ năm 2016. Khách hàng của tôi rất hài lòng với chuyện không nhìn thấy crash. Thực tế là trong 10 năm qua, mọi ứng dụng tôi triển khai lên production đều đạt 100% uptime. Không tính các sự cố phần cứng, hệ điều hành hay mạng nằm ngoài tầm kiểm soát của tôi
      Có lẽ bạn nên mở rộng góc nhìn hơn một chút
    • Tôi nghĩ Rails chỉ nhanh hơn Phoenix, xét về tốc độ phát triển, trong khoảng ngày đầu tiên mà thôi. Sau đó bạn sẽ đụng phải logic ngầm, những thứ như method_missing, và mất thêm thời gian để hiểu hệ thống hoạt động ra sao
      Elixir/Phoenix rõ ràng hơn nhiều ở điểm đó, nên về bảo trì lâu dài, tức là sau tuần đầu tiên, nó dễ chịu hơn hẳn. Không có trạng thái ẩn, không phải lần mò xem ModuleName.method(params) đến từ đâu, cũng không cần dựng sẵn thứ gì chỉ để chạy được method đó; chỉ cần truyền đúng tham số là xong. Điểm yếu chủ yếu là hệ sinh thái package sẵn có nhỏ hơn
    • Thử đoán xem Ruby Discord dùng gì nào?
    • Lý do Phoenix thú vị chủ yếu là OTP, channels và LiveView. Dù vậy, LiveView có lẽ sẽ không phải lựa chọn tôi chọn vào năm 2026, và nếu bạn không cần những tính năng kiểu đó thì sức hút của nó có thể ít hơn
      Ecto cũng không tệ
      Claude Code viết mã Elixir rất tốt
      Thật bất ngờ là dù có hay không có LLM, người ta vẫn năng suất hơn khi dùng công nghệ mình đã quen
    • Có một sự mỉa mai tuyệt đối trong câu “khi phạm vi ứng dụng chưa rõ mà lao ngay vào Go thì sẽ tốn token hơn rất nhiều, còn Rails thì cực kỳ hiệu quả”. Viết dài như vậy rồi cuối cùng lại tự lộ ra là thực ra đâu phải chính mình viết code đâu