Phản hồi của Haskell đối với Node.js là gì?

Tôi tin rằng cộng đồng Erlang không ghen tị với Node.js vì nó không chặn I / O nguyên bản và có các cách để mở rộng quy mô triển khai dễ dàng đến nhiều bộ xử lý (một thứ thậm chí không được tích hợp trong Node.js). Thêm chi tiết tại http://journal.dedasys.com/2010/04/29/erlang-vs-node-js và Node.js hoặc Erlang

Haskell thì sao? Haskell có thể cung cấp một số lợi ích của Node.js, cụ thể là một giải pháp sạch để tránh chặn I / O mà không cần phải lập trình đa luồng không?

Có nhiều điều hấp dẫn với Node.js

1. Sự kiện: Không có thao tác xử lý luồng, lập trình viên chỉ cung cấp các cuộc gọi lại (như trong khung Snap)
2. Các cuộc gọi lại được đảm bảo để chạy trong một luồng duy nhất: không có điều kiện cuộc đua nào có thể.
3. API thân thiện với UNIX đơn giản và đẹp. Tiền thưởng: Hỗ trợ HTTP tuyệt vời. DNS cũng có sẵn.
4. Mỗi I / O theo mặc định là không đồng bộ. Điều này làm cho nó dễ dàng hơn để tránh ổ khóa. Tuy nhiên, quá nhiều CPU xử lý trong một cuộc gọi lại sẽ ảnh hưởng đến các kết nối khác (trong trường hợp này, tác vụ sẽ được chia thành các tác vụ phụ nhỏ hơn và được lên lịch lại).
5. Cùng một ngôn ngữ cho phía máy khách và phía máy chủ. (Tuy nhiên, tôi không thấy quá nhiều giá trị trong cái này. JQuery và Node.js chia sẻ mô hình lập trình sự kiện nhưng phần còn lại thì rất khác. Tôi không thể thấy cách chia sẻ mã giữa phía máy chủ và phía máy khách có thể có ích trong thực tế.)
6. Tất cả điều này được đóng gói trong một sản phẩm duy nhất.

Ok, vì vậy đã xem một chút về bản trình bày của node.js mà @gawi chỉ cho tôi, tôi có thể nói thêm một chút về cách Haskell so sánh với node.js. Trong bài trình bày, Ryan mô tả một số lợi ích của Chủ đề xanh, nhưng sau đó tiếp tục nói rằng anh ta không thấy việc thiếu một chủ đề trừu tượng là một bất lợi. Tôi không đồng ý với vị trí của anh ấy, đặc biệt là trong bối cảnh của Haskell: Tôi nghĩ rằng sự trừu tượng mà các luồng cung cấp là rất cần thiết để làm cho mã máy chủ dễ dàng hơn để có được quyền và mạnh mẽ hơn. Đặc biệt:

• sử dụng một luồng trên mỗi kết nối cho phép bạn viết mã thể hiện giao tiếp với một máy khách, thay vì viết mã đó liên quan đến tất cả các máy khách cùng một lúc. Hãy nghĩ về nó như thế này: một máy chủ xử lý nhiều máy khách với các luồng trông gần giống như một máy chủ xử lý một máy khách; sự khác biệt chính là có một forknơi nào đó trước đây. Nếu giao thức bạn đang thực hiện hoàn toàn phức tạp, việc quản lý máy trạng thái cho nhiều máy khách đồng thời khá khó khăn, trong khi các luồng cho phép bạn chỉ cần kịch bản giao tiếp với một máy khách. Mã dễ dàng hơn để có được quyền, và dễ hiểu và bảo trì hơn.

• cuộc gọi lại trên một luồng hệ điều hành duy nhất là đa nhiệm hợp tác, trái ngược với đa nhiệm được ưu tiên, đó là những gì bạn nhận được với các luồng. Nhược điểm chính với đa nhiệm hợp tác là lập trình viên chịu trách nhiệm đảm bảo rằng không có nạn đói. Nó mất tính mô-đun: mắc lỗi ở một nơi và có thể làm hỏng cả hệ thống. Đây thực sự là điều bạn không muốn phải lo lắng, và sự ưu tiên là giải pháp đơn giản. Hơn nữa, giao tiếp giữa các cuộc gọi lại là không thể (nó sẽ bế tắc).

• đồng thời không khó trong Haskell, bởi vì hầu hết các mã là thuần túy và do đó an toàn cho luồng khi xây dựng. Có những nguyên thủy giao tiếp đơn giản. Việc tự bắn vào chân mình bằng Haskell khó hơn nhiều so với ngôn ngữ có tác dụng phụ không hạn chế.

Haskell có thể cung cấp một số lợi ích của Node.js, cụ thể là một giải pháp sạch để tránh chặn I / O mà không cần phải lập trình đa luồng không?

Vâng, trong thực tế các sự kiện và chủ đề được thống nhất trong Haskell.

• Bạn có thể lập trình trong các luồng nhẹ rõ ràng (ví dụ: hàng triệu luồng trên một máy tính xách tay).
• Hoặc là; bạn có thể lập trình theo kiểu điều khiển sự kiện không đồng bộ, dựa trên thông báo sự kiện có thể mở rộng.

Các luồng thực sự được triển khai theo các sự kiện và chạy trên nhiều lõi, với việc di chuyển luồng liền mạch, với hiệu suất được ghi lại và các ứng dụng.

Ví dụ cho

• ồ ạt đồng loạt công việc
• bộ sưu tập đồng thời chia tỷ lệ trên 32 hoặc 48 lõi
• công cụ hỗ trợ để định hình và gỡ lỗi các chương trình đa luồng / đa sự kiện .
• hiệu suất cao máy chủ web hướng sự kiện .
• người dùng thú vị: chẳng hạn như giao dịch cao tần .

Bộ sưu tập đồng thời nbody trên 32 lõi

Trong Haskell bạn có cả sự kiện và chủ đề, và vì đó là tất cả các sự kiện dưới mui xe.

Đọc bài viết mô tả việc thực hiện.

Trước tiên, tôi không giữ quan điểm của bạn rằng node.js đang thực hiện đúng cách phơi bày tất cả các cuộc gọi lại đó. Cuối cùng, bạn viết chương trình của mình theo CPS (kiểu tiếp tục truyền) và tôi nghĩ rằng đó là công việc của nhà soạn nhạc để thực hiện chuyển đổi đó.

Sự kiện: Không có thao tác xử lý luồng, lập trình viên chỉ cung cấp các cuộc gọi lại (như trong khung Snap)

Vì vậy, với suy nghĩ này, bạn có thể viết bằng cách sử dụng kiểu không đồng bộ nếu bạn muốn, nhưng bằng cách đó, bạn sẽ bỏ lỡ việc viết theo kiểu đồng bộ hiệu quả, với một luồng cho mỗi yêu cầu. Haskell rất hiệu quả ở mã đồng bộ, đặc biệt khi so sánh với các ngôn ngữ khác. Đó là tất cả các sự kiện bên dưới.

Các cuộc gọi lại được đảm bảo để chạy trong một luồng duy nhất: không có điều kiện cuộc đua nào có thể.

Bạn vẫn có thể có một điều kiện cuộc đua trong node.js, nhưng điều đó khó khăn hơn.

Mỗi yêu cầu là trong chủ đề riêng của nó. Khi bạn viết mã phải giao tiếp với các luồng khác, sẽ rất đơn giản để làm cho nó an toàn nhờ các nguyên hàm đồng thời của haskell.

API thân thiện với UNIX đơn giản và đẹp. Tiền thưởng: Hỗ trợ HTTP tuyệt vời. DNS cũng có sẵn.

Hãy xem trong hackage và xem cho chính mình.

Mọi I / O theo mặc định là không đồng bộ (mặc dù điều này đôi khi có thể gây khó chịu). Điều này làm cho nó dễ dàng hơn để tránh ổ khóa. Tuy nhiên, quá nhiều CPU xử lý trong một cuộc gọi lại sẽ ảnh hưởng đến các kết nối khác (trong trường hợp này, tác vụ sẽ được chia thành các tác vụ phụ nhỏ hơn và được lên lịch lại).

Bạn không có vấn đề như vậy, ghc sẽ phân phối công việc của bạn giữa các luồng hệ điều hành thực.

Cùng một ngôn ngữ cho phía máy khách và phía máy chủ. (Tuy nhiên, tôi không thấy quá nhiều giá trị trong cái này. Tuy nhiên, JQuery và Node.js chia sẻ mô hình lập trình sự kiện nhưng phần còn lại thì rất khác. Tôi không thể thấy cách chia sẻ mã giữa phía máy chủ và phía máy khách có thể có ích trong thực tế.)

Haskell không thể chiến thắng ở đây ... phải không? Hãy suy nghĩ lại, http://www.haskell.org/haskellwiki/Haskell_in_web_browser .

Tất cả điều này được đóng gói trong một sản phẩm duy nhất.

Tải ghc, cháy lên cabal. Có một gói cho mọi nhu cầu.

Cá nhân tôi thấy Node.js và lập trình với các cuộc gọi lại là mức độ thấp không cần thiết và một chút không tự nhiên. Tại sao chương trình với các cuộc gọi lại khi một thời gian chạy tốt như chương trình được tìm thấy trong GHC có thể xử lý các cuộc gọi lại cho bạn và thực hiện khá hiệu quả?

Trong khi đó, thời gian chạy GHC đã được cải thiện rất nhiều: giờ đây nó có "trình quản lý IO mới" được gọi là MIO trong đó "M" là viết tắt của đa lõi tôi tin. Nó xây dựng trên nền tảng của trình quản lý IO hiện tại và mục tiêu chính của nó là khắc phục nguyên nhân suy giảm hiệu năng của hơn 4 lõi. Con số hiệu suất được cung cấp trong bài báo này là khá ấn tượng. Tự mình trông thấy:

Với Mio, các máy chủ HTTP thực tế ở quy mô Haskell có tới 20 lõi CPU, đạt hiệu suất cao nhất tới 6,5 lần so với các máy chủ tương tự sử dụng các phiên bản GHC trước đó. Độ trễ của máy chủ Haskell cũng được cải thiện: [...] trong một mức tải vừa phải, giảm thời gian phản hồi dự kiến ​​5,7 lần khi so sánh với các phiên bản GHC trước đây

Và:

Chúng tôi cũng chỉ ra rằng với Mio, McNantara (bộ điều khiển SDN được viết bằng Haskell) có thể mở rộng hiệu quả tới hơn 40 lõi, đạt được hơn 20 triệu yêu cầu mới mỗi giây trên một máy và do đó trở thành nhanh nhất trong tất cả các bộ điều khiển SDN hiện có .

Mio đã đưa nó vào bản phát hành GHC 7.8.1. Cá nhân tôi thấy đây là một bước tiến lớn trong hiệu suất của Haskell. Sẽ rất thú vị khi so sánh hiệu suất ứng dụng web hiện có được biên dịch bởi phiên bản GHC trước đó và 7.8.1.

Sự kiện IMHO là tốt, nhưng lập trình bằng phương thức gọi lại thì không.

Hầu hết các vấn đề làm cho việc mã hóa và gỡ lỗi của các ứng dụng web trở nên đặc biệt đến từ những gì làm cho chúng có thể mở rộng và khả thi. Điều quan trọng nhất, bản chất không trạng thái của HTTP. Điều này giúp tăng khả năng điều hướng, nhưng điều này đặt ra sự đảo ngược của điều khiển trong đó phần tử IO (máy chủ web trong trường hợp này) gọi các trình xử lý khác nhau trong mã ứng dụng. Mô hình sự kiện này - hay mô hình gọi lại, nói chính xác hơn - là một cơn ác mộng, vì các cuộc gọi lại không chia sẻ phạm vi biến đổi và một cái nhìn trực quan về điều hướng bị mất. Rất khó để ngăn chặn tất cả các thay đổi trạng thái có thể xảy ra khi người dùng điều hướng qua lại, trong số các vấn đề khác.

Có thể nói rằng các vấn đề tương tự như lập trình GUI trong đó mô hình sự kiện hoạt động tốt, nhưng GUI không có điều hướng và không có nút quay lại. Điều đó nhân lên các chuyển đổi trạng thái có thể có trong các ứng dụng web. Kết quả của nỗ lực giải quyết các vấn đề này là các khung nặng với cấu hình phức tạp, nhiều định danh ma thuật phổ biến mà không đặt câu hỏi về gốc rễ của vấn đề: mô hình gọi lại và thiếu chia sẻ phạm vi biến đổi và không có trình tự, do đó trình tự phải được xây dựng bằng cách liên kết định danh.

Có các khung dựa trên tuần tự như ocsigen (ocaml) bên bờ biển (smalltalk) WASH (ngưng, Haskell) và mflow (Haskell) giải quyết vấn đề quản lý nhà nước trong khi duy trì khả năng điều hướng và tính ưu việt của REST. trong các khung này, lập trình viên có thể biểu thị điều hướng như một chuỗi bắt buộc trong đó chương trình gửi các trang và chờ phản hồi trong một luồng, các biến nằm trong phạm vi và nút quay lại hoạt động tự động. Điều này vốn đã tạo ra mã ngắn hơn, an toàn hơn, dễ đọc hơn trong đó điều hướng được hiển thị rõ ràng cho người lập trình. (cảnh báo công bằng: Tôi là nhà phát triển của mflow)

Câu hỏi khá vô lý vì 1) Haskell đã giải quyết vấn đề này theo cách tốt hơn nhiều và 2) gần giống như cách mà Erlang có. Đây là điểm chuẩn so với nút: http://www.yesodweb.com/blog/2011/03/prinating-warp-cross-lingu-benchmark

Cung cấp cho Haskell 4 lõi và nó có thể thực hiện 100k yêu cầu (đơn giản) mỗi giây trong một ứng dụng. Nút không thể làm nhiều như vậy và không thể mở rộng một ứng dụng trên các lõi. Và bạn không phải làm bất cứ điều gì để gặt hái điều này bởi vì thời gian chạy Haskell là không chặn. Ngôn ngữ duy nhất (tương đối phổ biến) có IO không chặn được tích hợp trong thời gian chạy là Erlang.

Giống như nodejs đã giảm libev , Khung Web Snap Haskell cũng đã giảm libev .