Tôi đã dành đủ thời gian vật lộn với Node.js và giờ tôi không còn cảm thấy phấn khởi khi làm việc với nó nữa, và có lẽ đây là lời chia tay chính thức của tôi. Và quan trọng hơn là giờ tôi cần người bảo trì!
Node.js là một công nghệ tương đối tốt, nhưng cuối cùng thì nó không phải là công cụ phù hợp cho loại phần mềm mà tôi quan tâm ngày nay. Tôi vẫn có kế hoạch sử dụng Node.js cho web site, nhưng nếu bạn muốn bảo trì thứ gì đó thì hãy cho tôi biết. Hãy để lại lời nhắn theo mẫu sau: tên Github của bạn, tên người dùng NPM, và (các) dự án! Và như mọi khi tôi chỉ xin các bạn đừng thay đổi API quá nhiều, bởi vì nếu bạn cần làm chuyện đó thì bạn nên làm luôn dự án mới đi cho lành.
Koa là dự án tôi sẽ tiếp tục bảo trì (cùng với Co và các bạn).
Chén thánh
Tôi luôn luôn yêu C, nhưng ai đã từng làm việc với C đều biết rằng nó rất tuyệt vời nhưng cũng rất dễ mắc sai lầm. Sẽ rất khó để chứng minh được đó là ngôn ngữ lập trình thường ngày vì nó không hẳn là ngôn ngữ dễ làm việc nhất. Sự đơn giản là thứ mà tôi luôn trân trọng ở C, nhưng nếu thiếu đi một đống include thì code không thể biên dịch.
Càng làm việc với các hệ thống phân tán, tôi càng cảm thấy bất mãn với phương hướng của Node.js, đề cao hiệu suất lên trên việc dễ sử dụng và sự bền bỉ. Chỉ riêng tuần vừa rồi tôi đã viết lại một hệ thống phân tán tương đối lớn trên Go; ngôn ngữ này bền bỉ hơn, hoạt động tốt hơn, dễ bảo trì hơn, và khả năng kiểm thử bao quát hơn vì code đồng bộ nói chung là đẹp hơn và dễ làm việc hơn.
Tôi không có ý nói Go là nhất, nó không hoàn hảo, nhưng trong các ngôn ngữ tồn tại ngày nay, Go là một giải pháp tuyệt hảo đối với tôi. Và khi mà những ngôn ngữ “thế hệ mới” như Rust và Julia tìm thấy chỗ đứng và trưởng thành hơn, tôi chắc rằng chúng ta sẽ có nhiều lựa chọn khác.
Cá nhân tôi rất hứng khởi với Go vì tốc độ nâng cấp, thật tuyệt khi nghe tin Google tích cực phát triển nhắm tới phiên bản 2.0, và từ những gì tôi biết thì họ không ngại có những đột phá ngay từ bây giờ, và điều đó thật hay.
Tôi sẽ rất hài lòng nếu đó là sự thực, đơn giản bởi vì tôi muốn thay đổi nhanh chóng nếu như nó mang lại giá trị thực sự cho ngôn ngữ. Nhưng tôi cũng không phải là một công ty phần mềm khổng lồ chạy những hệ thống lớn.
Vì sao lại là Go?
Node.js vẫn là một công cụ tốt, và nếu nó vẫn làm bạn hài lòng thì chẳng có lý do gì để lo lắng cả, nhưng nếu có gì đó làm bạn suy nghĩ, thì bạn nên bước ra khỏi chiếc hộp của mình và xem ngoài kia có gì mới; chỉ sau vài tiếng sử dụng Go tôi đã bị ghiền rồi.
Lần nữa, tôi không có ý nói Go là ngôn ngữ hay nhất, và bạn nhất định phải sử dụng nó. Nhưng Go rất trưởng thành và bền bỉ so với tuổi đời của nó (tương đương Node), tái cấu trúc với type thật đơn giản và dễ chịu, công cụ của Go cung cấp cho việc lập hồ sơ và sửa lỗi rất tốt, và cộng đồng Go có những tôn chỉ rõ ràng về tài liệu, định dạng, đo đạc hiệu năng, cũng như thiết kế API.
stdlib của Go là một thứ mà ban đầu tôi nghĩ thật tồi tệ khi tôi mới nghe nói về Go, vì quá quen thuộc với sự phân rã cực kỳ cao của Node, cũng như những trải nghiệm ghê rợn với stdlib của Ruby. Nhưng sau khi đào sâu vào Go, tôi nhận ra stdlib thực sự cần thiết với các chương trình ngày nay, nén, json, IO, IO bộ đệm, chỉnh sửa chuỗi ký tự, v.v. Phần lớn các API này được triển khai rõ ràng và mạnh mẽ. Bạn có thể dễ dàng viết cả chương trình chỉ sử dụng mỗi stdlib.
Các gói bổ sung từ bên thứ ba cho Go
Hầu như tất cả các thư viện cho Go đều nhìn và cảm nhận giống nhau, phần lớn các đoạn code từ bên thứ ba tôi đã sử dụng đều có chất lượng cao, một điều tương đối xa xỉ so với Node vì Javascript thu hút một phổ kỹ năng rộng hơn.
Do không có một kho thư viện chung cho Go nên đôi khi bạn sẽ tìm thấy 5-6 thư viện cùng tên, và đôi khi nó làm bạn cảm thấy rối rắm nhưng nó cũng có cái hay, bắt bạn phải xem xét kỹ càng để lựa chọn được giải pháp phù hợp. Với Node, thường là những thư viện kiểu mẫu như “redis”, “mongodb-native” hay “zeromq”, và bạn sẽ dừng ngay lại đó và coi những thư viện đó là nhất.
Go vs Node
Nếu bạn làm những công việc phân tán, bạn sẽ thấy các kiểu dữ liệu đồng thời tối giản của Go hữu dụng. Ta cũng có thể có được hiệu ứng tương tự trong Node với các chương trình khởi tạo, nhưng theo tôi thì chương trình khởi tạo chỉ đưa ta đi được nửa đường. Không có phương tiện xử lý lỗi stack và báo cáo riêng biệt thì nó cũng chỉ tầm thường thôi. Tôi cũng không muốn chờ 3 năm để cộng đồng chữa phân mảnh, trong khi ta có những giải pháp hoạt động tốt ngay tại thời điểm này.
Theo tôi, xử lý lỗi trong Go vượt trội hơn. Node rất hữu ích theo kiểu bạn phải nghĩ ra mọi tình huống lỗi và quyết định làm gì với những lỗi đó. Nhưng Node không đạt vì các lý do sau:
- Bạn có thể bị tái lặp điểm quay về
- Bạn có khi không có luôn điểm quay về (bị mất trong cõi hư vô)
- Bạn có thể bị lỗi ngoài ranh giới
- Điểm phát có thể sinh ra nhiều sự kiện “lỗi”
- Những lỗi thiếu đưa tất cả mọi thứ xuống địa ngục
- Thường ko biết cái gì cần xử lý “lỗi”
- Công cụ xử lý “lỗi” thường quá chi tiết
- Điểm quay về dở ẹc
Đối với Go, code của tôi chạy xong là xong, bạn không thể tái thực hiện câu lệnh. Điều này hoàn toàn khác trong Node, đôi khi bạn nghĩ rằng chương trình đã chạy xong rồi, cho đến khi một thư viện gọi một điểm quay về nhiều lần, hoặc không sử dụng đúng công cụ dọn dẹp, khiến cho chương trình chạy lại. Và điều này khiến cho bạn rất khó để chứng minh tính khả thi trên hệ thống sản xuất, vậy thì tốn công sức chứng minh làm gì? Những ngôn ngữ khác không hành hạ bạn như vậy.
Cá nhân tôi nghĩ các doanh nghiệp mới nổi nên tập trung vào hiệu năng thô ổn định, vì đó mới là cái tạo nên hay làm đổ vỡ quan hệ của bạn với khách hàng. Điều này đặc biệt đúng với các nhóm nhỏ, nếu bạn mất quá nhiều thời gian sửa code lỗi thì bạn làm gì có thời gian làm việc trên sản phẩm thực sự.
Điểm mạnh của Node, với tôi, là nó được viết bằng Javascript, và tôi nghĩ tận dụng ưu điểm đó là hợp lý nhất.
Tương lai của Node
Tôi vẫn mong Node sẽ phát triển, rất nhiều người đã đầu tư nhiều công sức vào đó, và nó thực sự có tiềm năng. Tôi nghĩ rằng Joyent và nhóm cần tập trung hơn vào tính hữu dụng, hiệu năng chẳng có ý nghĩa gì nếu phần mềm của bạn mong manh, khó sửa lỗi, khó tái cấu trúc cũng như khó viết.
Quả thực là, đến 4-5 năm sau chúng ta vẫn còn những lỗi mơ hồ như “Error: getaddrinfo EADDRINFO” cho thấy trọng tâm đang nằm ở đâu. Tôi cũng thông cảm là đôi khi ta quên mất những thứ như thế khi còn đang mải mê phát triển lõi của một hệ thống, nhưng tôi cũng nghĩ rằng người dùng đã nhiều lần đặt vấn đề này ra nhưng không có tiến triển gì cả. Và thường là ta nhận được những câu trả lời nhạt nhẽo khoe khoang rằng hệ thống đang có đã hoàn hảo rồi, trong khi sự thực là nó còn lâu mới vậy.
Xử lý stream kém cỏi, điểm quay về rất khó sử dụng, lỗi thì vu vơ, công cụ tầm thường, tôn chỉ của cộng đồng thì cũng có nhưng thua xa Go. Dẫu vậy vẫn có những việc tôi sử dụng Node, như xây dựng web site, và đôi khi là API hay bản thử nghiệm nào đó. Nếu Node có thể giải quyết được một vài vấn đề cơ bản thì có lẽ nó sẽ vẫn còn hữu dụng, nhưng chủ đề hiệu năng quan trọng hơn hữu dụng không còn ý nghĩa nữa khi mà bạn có một giải pháp khác chạy nhanh hơn và dễ sử dụng hơn.
Nếu cộng đồng Node quyết định gắn bó với hệ thống khởi tạo và có thể đưa nó vào lõi của node, để phát hiện lỗi sớm, thì có lẽ nó sẽ cạnh tranh được về phương diện đó. Điều này sẽ giúp Node dễ sử dụng hơn và bền bỉ hơn.
Tin vui là tôi đã nói chuyện với một vài người tài năng và dễ thương ở StrongLoop, những người đã có nhiều đóng góp cho lõi Node trong thời gian dài. Họ đang có hướng đi đúng khi lắng nghe người viết code phản ánh về nền tảng Node, và có kế hoạch tìm cách giải quyết những vấn đề còn tồn đọng, cũng như làm cho nó dễ sử dụng hơn trong những phiên bản sau của Node. Tôi không biết tranh chấp giữa những công ty khác nhau cùng phát triển lõi sẽ đi về đâu, nhưng tôi mong rằng phương diện dành cho những người viết code sẽ dành được ưu thế.
Tôi không muốn nhắm vào bất kỳ ai, rất nhiều người tài năng đã làm việc cùng và đóng góp vào cho Node, nhưng tôi không còn quan tâm nữa. Tôi đã có thời gian tuyệt vời với cộng đồng và gặp được nhiều người rất hay.
Tóm lại là bạn đừng tự nhốt mình vào trong bong bóng của mình. Hãy tìm hiểu những gì có ngoài kia, và có khi bạn sẽ lại khoái lập trình. Có rất nhiều giải pháp tuyệt vời ngoài đó, và sai lầm của tôi là đã chờ quá lâu mới nghịch chúng! :).
Nguồn: Code Aventures
Bình luận