Gleam OTP – Phát triển chương trình đa lõi chịu lỗi dựa trên actor
(github.com/gleam-lang)- Gleam OTP hỗ trợ phát triển chương trình có khả năng chịu lỗi và hiệu năng đa lõi bằng cách tận dụng mô hình actor
- Điểm nổi bật là hướng tới an toàn kiểu hoàn toàn và tương thích với Erlang OTP
- Cung cấp khả năng khôi phục sự cố và tự phục hồi thông qua supervisor
- Chỉ cung cấp một phần tính năng của Erlang/OTP, và các chiến lược quản lý bổ sung hiện đang được phát triển
- Hỗ trợ nhiều loại actor khác nhau như process, actor, supervisor
Tổng quan về Gleam OTP
- Gleam OTP là một framework actor mạnh mẽ tham chiếu kiến trúc OTP của Erlang, phù hợp để xây dựng các chương trình đa lõi có khả năng chịu lỗi
- Đây là dự án mã nguồn mở được phát hành theo giấy phép Apache-2.0
Các đặc điểm và ưu điểm chính
- Đảm bảo an toàn kiểu hoàn toàn cho actor và message
- Cung cấp khả năng tương thích với Erlang OTP, giúp dễ dàng tích hợp với môi trường Erlang hiện có
- Hỗ trợ chịu lỗi thông qua supervisor, bao gồm phát hiện lỗi, tự động khôi phục và quản lý dừng tiến trình
- Hướng tới mức hiệu năng tương đương Erlang OTP
- Có tài liệu và ví dụ, giúp dễ học và áp dụng thực tế
Giải thích theo từng loại actor
-
Process
- Đóng vai trò là khối xây dựng cơ bản nhất trong OTP
- Là nền tảng cho các loại actor khác, nhưng trong ứng dụng Gleam thường không được dùng trực tiếp nhiều
-
Actor
- Là loại process được sử dụng phổ biến nhất, cung cấp chức năng tương tự gen_server của Erlang
- Tự động xử lý các system message của OTP, đồng thời kích hoạt khả năng debug và tracing
-
Supervisor
- Có nhiệm vụ khởi động các process khác và giám sát cũng như khôi phục chúng
- Tự động khởi động lại child process khi gặp crash hoặc tình huống ngoại lệ
- Hình thành cấu trúc chịu lỗi của ứng dụng thông qua cấu trúc lồng nhau của supervisor (supervision tree)
- Có thể xem chi tiết triển khai trong tài liệu
gleam/otp/static_supervisor,gleam/otp/factory_supervisor
Giới hạn và vấn đề
- Hiện tại actor chưa hỗ trợ mọi system message của OTP, và các message chưa được hỗ trợ sẽ bị bỏ qua
- Một số tính năng của API debug OTP còn bị giới hạn
- Khi cần, có thể tạo issue để yêu cầu hỗ trợ cho các message chưa được triển khai
Kết luận và ý nghĩa của dự án
- Gleam OTP mở rộng các thế mạnh của hệ sinh thái Erlang sang ngôn ngữ Gleam, có ý nghĩa lớn ở khả năng hiện thực hóa an toàn kiểu và khả năng chịu lỗi đa lõi
- Phù hợp với các ứng dụng mà độ ổn định và hiệu năng là yếu tố quan trọng trong môi trường production
- Đây là một dự án mã nguồn mở có giá trị học tập và ứng dụng thực tiễn cao cho startup, lập trình viên chuyên môn IT và cả lập trình viên nói chung
1 bình luận
Ý kiến trên Hacker News
Nếu bạn quan tâm đến kiểu tĩnh, môi trường không có null, lập trình hàm, hoặc các ngôn ngữ họ ML thì tôi khuyên nên thử gleam
Và tất nhiên nó cũng chạy trên BEAM
Khi cài gleam, hệ thống của tôi cài thêm khoảng 50 gói, chắc là các gói liên quan đến Erlang/Elixir
Tôi tự hỏi sẽ thế nào nếu chỉ muốn transpile sang JS. Có lẽ đây cũng có thể là vấn đề đóng gói trên hệ thống của tôi
Nếu hỗ trợ Lua làm đích transpile thì còn tuyệt hơn nữa. Theo tôi, nếu muốn nhúng DSL vào chương trình khác thì Lua dễ hơn runtime JS phải gấp 3 lần
Trên hết, điều tôi thích nhất cho đến giờ là cộng đồng. Chất lượng thư viện và tài liệu trong cộng đồng gleam cực kỳ cao
Nó làm tôi nhớ đến cộng đồng Rust, nơi người thông minh đã xử lý sẵn các bài toán khó và đăng lên những cách giải rất tốt (lustre, squirrel, v.v.)
Một điểm nổi bật nữa là có rất nhiều thử nghiệm và nỗ lực sáng tạo. Những thứ ít thấy trong hệ sinh thái ngôn ngữ lớn lại nổi bật ở đây. Khi cộng đồng phát triển lên, bầu không khí cũng rất chào đón
Bạn có thể gợi ý nên bắt đầu học từ đâu không
Tôi đang tìm hiểu vì nếu có thể dùng Gleam cùng framework như Phoenix thì nghe sẽ rất tuyệt
Hiện tôi đang chuẩn bị một dự án mới bằng Python, nhưng nếu có lựa chọn khả dụng với Gleam thì tôi cũng muốn thử
Điểm hay là có thể rất dễ dàng quyết định phần nào nằm ở frontend/backend
Liên kết YouTube
Nhưng có các công cụ thường dùng khi xây dựng web app
Lustre là công cụ view cơ bản, còn Wisp đóng vai trò server
Với SQL thì có squirrel và POG (mới hơn nhưng đang được ưa chuộng)
Đây là lựa chọn tốt nếu bạn cần một phương án kiểu tĩnh khác trên BEAM
Nó giống như một phương ngữ của Haskell, dùng strict evaluation và hỗ trợ row polymorphism
Tôi muốn biết trong thực tế nó được dùng như thế nào. Người ta có xây toàn bộ logic dịch vụ bằng nó không, hay chỉ dùng cho một số phần nhất định
Chúng tôi đẩy mẫu hình "functional core, imperative shell" đến mức tối đa, tách Gleam ra để xử lý các tác vụ tính toán nặng trong codebase Ruby on Rails hiện có
Gần như không dùng các tính năng OTP, và để Rails chỉ tập trung vào đúng thế mạnh vốn có như web UI/HTTP API
Rails đảm nhiệm việc thiết lập giá trị đầu vào cho job, rồi dữ liệu job được truyền sang Gleam qua Redis dưới dạng một tập giá trị nguyên tử duy nhất
Chúng tôi tạo một lớp bọc mỏng bằng Elixir chỉ để xử lý network và file IO, còn business logic nằm trong các module Gleam
Tôi định sẽ sớm viết một bài kỹ thuật chi tiết hơn về cách làm này. Đây là chủ đề thường được quan tâm trên HN
Elixir là một ngôn ngữ rất tuyệt cho mục đích tổng quát và có thế mạnh ở nhiều lĩnh vực
Nếu muốn nghe chi tiết hơn thì xem video Developer Voices của tôi
Liên kết YouTube
Có rất nhiều người đang nghiêm túc xây dựng hệ thống chỉ với Erlang/Elixir & BEAM, nên nếu có gì thắc mắc thì họ sẽ trả lời rất tốt
Khi đã hiểu OTP đủ sâu, việc xây toàn bộ hệ thống trên đó trở nên rất tự nhiên
Tôi đã làm như vậy suốt 7 năm, nhưng cũng thấy rằng lập trình viên mới mất khá nhiều thời gian để quen với hệ sinh thái này
Tôi không hiểu vì sao lại cần đưa chuyện chính trị vào trang của một dự án kỹ thuật
Đây không phải vấn đề đồng ý hay không, mà tôi nghĩ trong bối cảnh chuyên môn thì tốt hơn nên bỏ các thảo luận kiểu này ra ngoài
Nếu không thì cuộc trò chuyện sẽ bị chệch khỏi trọng tâm một cách không cần thiết
chỉ xuất hiện đúng một lần ở cuối trang đó?
Nếu ai đó quyết định không dùng chỉ vì một câu như vậy, thì tôi nghĩ nó đang hoạt động đúng như chủ đích ban đầu
Nhưng tôi lại thấy chính bạn là người đã làm nó chệch khỏi trọng tâm
Theo tiêu chí của tôi, để có khả năng chịu lỗi và đa lõi thì dùng software transactional memory và hệ thống functional effects như Scala/ZIO sẽ tốt hơn
Dù vậy, khi cần thì mô hình actor vẫn có thể dùng được
Thêm nữa, xét về độ trưởng thành của hệ sinh thái JVM, khả năng quan sát và tính thực chiến thì nó vượt BEAM
Tôi hiểu việc phê bình các điểm yếu của BEAM, nhưng chỉ trích ngay cả những điểm mạnh của nó thì tôi không đồng tình lắm
BEAM hoạt động bằng cách truyền các thông điệp immutable giữa các green thread nhẹ và rẻ
Nó có hệ thống giám sát vững chắc (supervisor trees), nên không phải lo về data race hay thread bị treo
Tất cả những thứ này đều được tích hợp sẵn nên không có nhiều boilerplate
Nhờ tính bất biến mà hiệu năng cũng tốt hơn mong đợi
Rốt cuộc, BEAM là nền tảng được tối ưu nhất cho các hệ thống chịu lỗi, phân tán và đồng thời
Một trong những yếu tố lớn tạo nên độ bền đó là cơ chế supervising mạnh mẽ và hạ tầng xuyên máy
Đây là ngôn ngữ đã truyền cảm hứng lớn cho sự ra đời của actor system
Nói theo nghĩa đen thì Erlang tồn tại chính vì mục tiêu này, và nó làm điều đó cực kỳ tốt
Nếu có dữ liệu thực sự cần chia sẻ thì dữ liệu đó bắt buộc phải là immutable
Thứ duy nhất tôi nghĩ ra là các phép tính số cực nặng, mà những thứ đó thì người ta không viết trực tiếp bằng elixir hay erlang mà sẽ hiện thực bằng NIF
Ngay cả khi không dùng tường minh actor pattern, việc truyền trạng thái hay điều phối cũng đều là bài toán đã được giải quyết
Có sẵn các primitive cơ bản như task, agent, GenServer, Supervisor, v.v.