Lập trình đồng thời Erlang và Go, sự khác biệt khách quan giữa CSP và Actors?

Tôi đã xem xét lập trình đồng thời trong các ngôn ngữ lập trình Erlang và Go. Theo phát hiện của tôi, họ được sử dụng mô hình Actor và CSP tương ứng.

Nhưng tôi vẫn bối rối với sự khác biệt khách quan giữa CSP và Diễn viên là gì? Có phải chỉ là lý thuyết khác nhau nhưng cùng một khái niệm?

— nish1013
nguồn

Chà, chúng không giống nhau vì Go cung cấp một bộ nguyên thủy khác với Erlang. Ngoài ra, Go thấp hơn nhiều so với Erlang và C-like.

— Daniel Gratzer

Các câu hỏi về ngôn ngữ, công nghệ hoặc dự án nào nên đưa ra tiếp theo là lạc đề về Lập trình viên, vì chúng chỉ có thể thu hút ý kiến chủ quan cho câu trả lời. Có quá nhiều yếu tố riêng lẻ đằng sau câu hỏi để tạo ra câu trả lời sẽ có giá trị lâu dài. Đề nghị đọc: Gorilla vs Shark

— gnat

@gnat Tôi không đồng ý, đây là câu hỏi về sự khác biệt khách quan giữa CSP và Diễn viên. Đó là một câu hỏi hoàn toàn hợp lý

— Daniel Gratzer

Câu hỏi không phải là tốt hay xấu mà là sự khác biệt cần xác định, do đó câu hỏi này cụ thể và không phải là nguyên nhân cho cuộc tranh luận chủ quan.

— nish1013

Có một câu trả lời rất hay cho câu hỏi này trên Lý thuyết StackExchange của CS: Sự khác biệt giữa Mô hình diễn viên đồng thời và Giao tiếp các quy trình tuần tự

— Jörg W Mittag

Trong thực tế, có rất ít sự khác biệt: cả hai đều đại diện cho các đơn vị thực hiện riêng biệt có giao diện chính với thế giới bên ngoài thông qua các tin nhắn.

Sự khác biệt là trong các chi tiết thực hiện của các ngôn ngữ. Dưới đây là một vài chi tiết như vậy:

Các kênh trong Go được gõ; nếu bạn muốn gửi tin nhắn với dữ liệu khác nhau, bạn cần các kênh riêng biệt. Với Erlang, người ta receivenhận được mọi thứ được gửi đến quy trình và phải khớp mẫu (trong Go, bạn sẽ sử dụng a selectvới nhiều trường hợp, do đó mã sẽ trông rất giống nhau, chỉ với các kênh khác nhau).
Bất cứ ai cũng có thể đọc hoặc viết một kênh Go. Trong Erlang, bất kỳ ai cũng có thể gửi tới một quy trình, nhưng chỉ quy trình đó mới nhận được. Điều này trở nên quan trọng nếu bạn muốn phân chia một nhiệm vụ giữa nhiều công nhân: trong Erlang bạn cần tạo quy trình phân phối, trong khi Go có thể chỉ cần chia sẻ một kênh.
Erlang cung cấp một đường dẫn trong suốt (hầu hết) để phân phối các quy trình trên nhiều máy chủ / VM. Goroutines bị giới hạn trong một quy trình duy nhất (mặc dù có các thư viện để phân phối).
Xử lý lỗi rất khác nhau. Erlang coi mỗi quy trình là độc lập: một lỗi trong một quy trình (giả sử chia cho 0) sẽ không ảnh hưởng đến bất kỳ quy trình nào khác trừ khi bạn liên kết rõ ràng với chúng (mặc dù điều gì đó đang chờ thông báo từ quy trình chết sẽ bị treo). Goroutines tất cả chạy trong cùng một không gian quá trình; một số chia cho 0 sẽ lấy toàn bộ chương trình.
Trong Erlang, dữ liệu là bất biến. Điều này có nghĩa là tất cả giao tiếp giữa một quá trình và thế giới bên ngoài diễn ra thông qua các tin nhắn. Go cho phép bạn chia sẻ trạng thái giữa các con khỉ đột (mặc dù bạn không nên).

Điểm cuối cùng này, tôi nghĩ là quan trọng nhất. Trong khi cả hai thông điệp sử dụng như là chính phương tiện truyền thông, Erlang làm cho đảm bảo mạnh hơn nhiều về cách thức và thời nhà nước có thể thay đổi.

— tập hợp
nguồn