Học Erlang vs học node.js [đã đóng]

Tôi thấy rất nhiều điều tào lao trực tuyến về cách Erlang đá vào mông của node.js chỉ trong mỗi danh mục có thể hiểu được. Vì vậy, tôi muốn tìm hiểu Erlang và cho nó một shot, nhưng đây là vấn đề. Tôi thấy rằng tôi gặp khó khăn hơn nhiều trong việc chọn Erlang so với khi tôi chọn node.js. Với node.js, tôi có thể chọn một dự án tương đối phức tạp và trong một ngày tôi có một cái gì đó hoạt động. Với Erlang, tôi gặp phải rào cản và sẽ không đi nhanh như vậy.

Vì vậy, đối với những người có nhiều kinh nghiệm hơn, Erlang có phức tạp để học không, hay tôi chỉ thiếu một cái gì đó? Node.js có thể không hoàn hảo, nhưng tôi dường như có thể hoàn thành công việc với nó.

Trước hết, tôi đồng ý với câu trả lời đúng của OPINION về việc học Erlang. Đó là ngôn ngữ chủ yếu là chức năng (mặc dù đồng thời đóng vai trò lớn) và tất cả các tính năng của nó đã được thêm vào để hướng tới khả năng chịu lỗi và độ mạnh, không hoàn toàn giống với mục tiêu thiết kế như Javascript ở nơi đầu tiên.

Thứ hai, việc để Node.js vào Erlang là một chút thất lạc. Node.js là một máy chủ / khung duy nhất thực hiện mọi thứ theo cách hướng sự kiện với sự trợ giúp của các cuộc gọi lại. Erlang có khung riêng (OTP), nhưng nó không ở cùng cấp độ.

Nếu bạn có kế hoạch học Erlang, tôi đề nghị mục blog của tôi Thư mở cho người mới bắt đầu Erlang (hoặc Onlooker) là phần giới thiệu đọc trước khi đi sâu vào hướng dẫn.

Điều duy nhất bạn có thể so sánh Erlang và Node.js về mặt mô hình và cách sử dụng là cách chúng được điều khiển theo sự kiện. Tuy nhiên, có hai sự khác biệt lớn ở đây. Mô hình của Node.js dựa trên các cuộc gọi lại bị ràng buộc với các sự kiện. Erlang dựa trên hàng đợi tin nhắn và nhận chọn lọc. Ý nghĩa trong đó là gì?

Trước hết, nếu bạn thực hiện mọi thứ theo cách gọi lại, cách duy nhất bạn mang theo trạng thái là đưa nó ra toàn cầu hoặc tham gia vào lập trình kiểu tiếp tục. Thứ hai, bạn phải tự chăm sóc cho ma trận sự kiện đầy đủ. Một ví dụ về điều này là nếu chúng ta tưởng tượng ra một cỗ máy trạng thái hữu hạn rất đơn giản: một semaphore mutex, hướng sự kiện.

Semaphore mutex có hai trạng thái: khóa và miễn phí. Bất cứ khi nào một đơn vị tính toán nhất định (worker, process, function hoặc thread) muốn có quyền truy cập vào mutex, nó phải kích hoạt một sự kiện cho biết 'Tôi quan tâm'. Bây giờ bạn phải quan tâm đến các loại sự kiện sau:

• Mutex là miễn phí và bạn yêu cầu lấy khóa
• Mutex bị khóa bởi người khác và bạn muốn lấy khóa
• Mutex bị khóa bởi chính bạn và bạn muốn giải phóng mutex

Sau đó, bạn có các sự kiện bổ sung để xem xét, chẳng hạn như hết thời gian để tránh bế tắc:

• Mutex đã bị khóa và bạn chờ đợi quá lâu, đồng hồ bấm giờ sẽ từ bỏ đám cháy
• Mutex đã bị khóa và bạn đợi quá lâu, lấy được khóa, sau đó hết thời gian chờ

Sau đó, bạn cũng có các sự kiện ràng buộc:

• bạn chỉ khóa mutex trong khi một số công nhân mong đợi nó được miễn phí. Bây giờ truy vấn của công nhân phải được xếp hàng để khi rảnh, nó được xử lý lại
• Bạn cần làm cho tất cả các công việc không đồng bộ

Ma trận sự kiện trở nên phức tạp rất nhanh. FSM của chúng tôi ở đây chỉ có 2 tiểu bang. Trong trường hợp Erlang (hoặc bất kỳ ngôn ngữ nào có nhận và chọn không đồng bộ với các sự kiện có khả năng đồng bộ), bạn phải quan tâm đến một vài trường hợp:

• Mutex là miễn phí và bạn yêu cầu lấy khóa
• Mutex bị khóa bởi người khác và bạn muốn lấy khóa
• Mutex bị khóa bởi chính bạn và bạn muốn giải phóng mutex

Và đó là nó. Bộ hẹn giờ được xử lý trong các trường hợp tương tự như việc nhận được thực hiện và đối với mọi việc phải làm với 'đợi cho đến khi nó miễn phí', các tin nhắn sẽ tự động được xếp hàng: nhân viên chỉ phải chờ trả lời. Mô hình là nhiều, đơn giản hơn nhiều trong những trường hợp này.

Điều này có nghĩa là trong các trường hợp chung, các mô hình dựa trên CPS và gọi lại như mô hình trong node.js yêu cầu bạn phải rất thông minh trong cách xử lý các sự kiện hoặc yêu cầu bạn xử lý toàn bộ ma trận sự kiện phức tạp, bởi vì bạn phải được gọi lại cho từng trường hợp không quan trọng xuất phát từ các vấn đề thời gian kỳ lạ và thay đổi trạng thái.

Nhận có chọn lọc thường cho phép bạn chỉ tập trung trong một nhóm nhỏ của tất cả các sự kiện tiềm năng và cho phép bạn suy luận dễ dàng hơn nhiều về các sự kiện trong trường hợp đó. Lưu ý rằng Erlang có một hành vi (mẫu thiết kế / triển khai khung) của một cái gì đó được gọi gen_event. Việc triển khai gen_event cho phép bạn có một cơ chế rất giống với những gì đang được sử dụng trong node.js nếu đó là những gì bạn muốn.

Sẽ có những điểm khác biệt chúng; Erlang có khả năng lập lịch ưu tiên trong khi node.js hợp tác, Erlang thích hợp hơn với một số ứng dụng quy mô lớn (phân phối và tất cả), nhưng Node.js và cộng đồng của nó thường có nhiều thông tin và hiểu biết về xu hướng web mới nhất. Đó là một câu hỏi về việc chọn công cụ tốt nhất và điều này sẽ phụ thuộc vào nền tảng của bạn, loại vấn đề và sở thích của bạn. Trong trường hợp của tôi, mô hình của Erlang rất phù hợp với cách suy nghĩ của tôi. Đây không phải là trường hợp cho tất cả mọi người.

Hi vọng điêu nay co ich.

Erlang không phức tạp để học, nó chỉ xa lạ với suy nghĩ rằng Hằng số Chambers (99,44%) của các lập trình viên đã học khi cách lập trình hoạt động. Vấn đề bạn gặp phải có lẽ chỉ là sự mất phương hướng về khái niệm hơn là sự phức tạp thực sự.

Dưới đây là một số tính năng xa lạ của Erlang sẽ cắn một lập trình viên điển hình:

• Erlang là một ngôn ngữ lập trình chức năng (chủ yếu là). Hầu hết các ngôn ngữ lập trình phổ biến hầu như bắt buộc.
• Mô hình đồng thời của Erlang là mô hình Diễn viên. Hầu hết các ngôn ngữ lập trình phổ biến đều sử dụng phân luồng dựa trên khóa hoặc một số hình thức tiếp cận dựa trên "lò phản ứng" để tương tranh. (Tôi nghĩ Node.js là cái sau, nhưng đừng gọi tôi trên đó - Tôi không quan tâm đến JavaScript ở bất kỳ khía cạnh nào của mối quan hệ máy khách / máy chủ.)
• Erlang có cách tiếp cận "để nó sập" để mã hóa với các tính năng thời gian chạy mạnh mẽ có sẵn để bắt những sự cố này, chẩn đoán chúng và vá nóng chúng trong khi hệ thống đang chạy. Hầu hết các ngôn ngữ lập trình phổ biến đều tán thành một phong cách lập trình phòng thủ nặng nề.
• Erlang gần như, nhưng không hoàn toàn, được kết hợp chặt chẽ với một thư viện xoắn lớn và nhẹ của các kiến ​​trúc thường được sử dụng cho các máy chủ ổn định và đáng tin cậy (OTP). (Có một lý do tại sao Erlang thường được gọi là Erlang / OTP.) Hơn nữa thư viện này được xây dựng trên các tính năng của người ngoài hành tinh được đề cập trước đó và do đó không rõ ràng đối với người mới. Hầu hết các ngôn ngữ lập trình đều có ít thư viện bao gồm tất cả (mặc dù Java EE) để làm việc và nói rằng các thư viện được xây dựng trên các khái niệm quen thuộc với hầu hết các lập trình viên.

Vì vậy, học Erlang sẽ là một thách thức đối với hầu hết các lập trình viên hơn là học Node.js - đặc biệt là nếu lập trình viên đã quen với JavaScript. Tuy nhiên, cuối cùng, một khi bạn vượt qua rào cản về khái niệm, tôi gửi rằng mã hóa Erlang sẽ ít phức tạp hơn mã hóa Node.js tương đương. Đây là một số lý do:

• Mô hình đồng thời của Erlang làm cho luồng logic rõ ràng hơn nhiều so với đồng thời kiểu "lò phản ứng" điển hình và làm cho đồng thời ổn định và chính xác hơn nhiều so với đồng thời dựa trên khóa thông thường. Hầu như không có vấn đề gì với một lập trình viên Erlang để bỏ hàng ngàn tiến trình trong một chương trình điển hình trong khi thả hàng ngàn luồng vào, nói, Java sẽ là một cơn ác mộng của sự tranh chấp (không đề cập đến bộ nhớ và chi phí CPU liên quan) và tương đương với việc duy trì hàng ngàn trạng thái riêng biệt trong thiết lập dựa trên "lò phản ứng" sẽ là một cơn ác mộng khi đọc.
• Là một ngôn ngữ chức năng (chủ yếu là), Erlang có rất nhiều thiết lập "những gì bạn thấy là những gì bạn nhận được". Các biến, một khi được đặt, không thay đổi. Không bao giờ. Không có OOP "hành động ma quái ở xa" làm bạn bối rối: bất cứ điều gì bạn làm việc cùng được trình bày rõ ràng trước mặt bạn. Không có biến kế thừa từ X và không có biến lớp từ Y và không có biến toàn cục từ Z để bạn quan tâm. (Điểm sau này không đúng 100%, nhưng nó đúng trong số lượng lớn các trường hợp như vậy đủ tốt cho giai đoạn học tập của bạn.)
• Các phương tiện mạnh mẽ mà Erlang có để xử lý lỗi có nghĩa là bạn làm lộn xộn mã của mình với chương trình phòng thủ ít hơn, do đó giữ cho logic rõ ràng hơn và giữ cho mã nhỏ.
• Thư viện OTP, một khi bạn tìm kiếm nó, là một tập hợp mã phổ biến cực kỳ mạnh mẽ, giữ cho toàn bộ ứng dụng của bạn thường xuyên và giải quyết nhiều vấn đề cũng như sử dụng các máy chủ tồn tại lâu mà bạn có thể sẽ không nghĩ đến cho đến khi quá muộn. Thư viện OTP, IM (ns) HO là một lý do đủ tốt để tìm hiểu Erlang.

Tiếp tục slogging đi tại Erlang nếu bạn có thể, và nếu bạn chưa làm như vậy, hãy truy cập Learn You some Erlang for Great Good để có phần giới thiệu nhẹ nhàng và (chủ yếu-) về các khái niệm của Erlang.

Có một vài khác biệt đáng kể giữa Erlang và Node

Đầu tiên là nút đó là Javascript, có nghĩa là ngôn ngữ rất phổ biến của nó có nhiều đặc điểm với các ngôn ngữ mà nhiều người quen thuộc hơn nên thường dễ dàng hơn để bắt đầu và chạy. Erlang thường có một cú pháp lạ và lạ đối với hầu hết, và mặc dù ngôn ngữ đơn giản hơn nhiều so với javascript, nhưng nó cần nhiều hơn một chút để làm quen với tính độc đáo của nó

Thứ hai là Erlang có một mô hình tương tranh không chia sẻ rất đặc biệt, nó đòi hỏi bạn phải suy nghĩ theo một cách khác để giải quyết vấn đề, đó là một điều tốt (TM)

Điều quan trọng cuối cùng là Erlang được phát triển bởi một công ty thương mại và có nguồn gốc sau khi thực tế, chỉ 2 năm trước đây, mọi người thực sự có thể thấy các cam kết cá nhân trong kiểm soát nguồn và thậm chí bây giờ tôi không nghĩ tất cả các nhà phát triển erlang đã di chuyển để repo github công cộng cho sự phát triển của họ. node.js được xây dựng bên trong cộng đồng ngay từ đầu, điều này có nghĩa là sự hỗ trợ cộng đồng của nó tốt hơn rất nhiều, đã có nhiều thư viện hơn cho nút, nhiều tài liệu cộng đồng hơn, nhiều ví dụ trực tiếp hơn, trình quản lý gói phổ biến, v.v. Erlang đang bắt kịp về vấn đề này nhưng nó vẫn là một đoạn đường nối lớn hơn nhiều để đứng dậy.

Node sẽ cho phép bạn lập trình những điều thú vị khá nhanh chóng và tương đối không đau đớn, nó vẫn còn những nỗi đau ngày càng tăng đối với các ứng dụng lớn mà erlang đã giải quyết trong một thời gian dài. Erlang sẽ thay đổi cách bạn lập trình và (imo) giúp bạn trở thành một lập trình viên tốt hơn, tuy nhiên nó sẽ không làm cho cuộc sống của bạn dễ dàng ngay từ đầu. Cả hai đều vui vẻ theo những cách khác nhau.