Tôi yêu Go và tôi cũng ghét Go?
Tôi thích Go ngay từ đầu. Tương tự với C và Java, tôi cảm thấy rất thân thuộc với các ví dụ, các tutorials dễ hiểu để tôi có thể viết code ngay. Tôi đã từng muốn học Go vì sự nổi tiếng của ngôn ngữ này trong vài năm trở lại đây.
I Love Go
Ưu tiên đầu tiên của tôi là cố gắng để bản thân không trở nên quá khờ khạo. Tôi học được điều này từ các dev Go thực sự: họ không cần đặt ra quá nhiều câu hỏi vẫn có thể code được. Họ không theo hướng dẫn nào cả. Khi nhận ra sự nhạy cảm với độ rộng 80 cột đem đến “nỗi nhớ” không mấy thú vị, tôi đã tìm kiếm 1 line length max. Nhưng lại không có. Tuy nhiên, sau đó tôi phát hiện được gofmt – 1 công cụ đơn giản mà Go tuyển chọn để giải phóng các dev khỏi tính chuyên chế trong cú pháp của ngôn ngữ này. Nó hỗ trợ Go code và đưa nó về với One True Style. Tôi thích điều đó. Tôi sinh ra trong nền công nghiệp cơ khí với 1 hướng dẫn phong cách chuẩn xác nhưng bất kì hướng dẫn style nào cũng có lỗ hổng. Khi “phe phái” hình thái, các nhà truyền bá phong cách phải đối mặt với những người xem chỉ dẫn là tài liệu sống. Tôi đã cập nhật .vimrc từ mấy đời trước thành gofmt. Những “kẻ độc tài” Go đang trở thành chính phong cách độc tài của tôi.
Một trong những lý do khiến tôi từ bỏ C++ (98, 11, and 14) là vì nó càng ngày càng màu nhiệm. Trong khi đó, Go lại hoàn toàn đơn giản và đây chính xác là điều tôi muốn. Các thư viện và ví dụ đều dễ hiểu. Các thông báo lỗi đều không khó hiểu (nói cách khác là chúng nhanh chóng giải quyết sự nhầm lẫn về methods với các “pointer receivers”) trong khi đối lập với nó, Rust lại có những lỗi đọc như các forms thuế không thể giải thích nổi.
Lý do Go không có tính kế thừa (như các ngôn ngữ OOP khác) thực ra rất dễ để lý giải. Các interfaces của nó đều có ý nghĩa và tính thực tiễn. Bạn không cần xác định 1 cấu trúc để thực hiện 1 interface. Bạn có thể sử dụng 1 giao diện để miêu tả bất kì điều gì đang thực hiện nó. Đơn giản, đúng không? Tính năng này đặc biệt hữu ích khi bạn testing. Trong 1 môi trường hỗn loạn với các thành phần vượt qua tầm kiểm soát, bạn có thể áp dụng các interfaces vào code của người khác và sau đó đem ra thử nghiệm.
Chuỗi công cụ cũng rất dễ sử dụng – đây cũng chính là lợi ích của việc bắt đầu từ còn số không. Chuỗi công cụ sẽ hỗ trợ bạn compile, test nhanh chóng và tích hợp dễ dàng với hệ sinh thái có quy mô tốt. Tôi đã không còn lo lắng về các dependencies, rebuilding… khi biết rằng khi Go chạy, GO sẽ tìm ra các lỗi cực kì nhanh gọn ở bất kì nơi nào mà tôi đã vận hành các lỗi đó.
Và tôi cũng ghét Go
Go là 1 ngôn ngữ “ngoan cố”. Hầu hết các sản phẩm thành công đều phân định rõ ràng về những gì chúng đang có, những gì chúng không có; trong khi Go lại là 1 cá thể đặc biệt. Tôi đã bị mê hoặc bởi đặc tính rõ ràng của Go nhưng đối với 1 số dev độc đoán sẽ thấy những điều đó khá kì quái và khó chịu.
Sau khi đọc những tài liệu chính thức, tôi nhận thấy chính mình đang ở giữa giai đoạn được bắt đầu với cụm “liệu GOOS có được thiết kế cho plan9 hay không” (Plan-9 là một hệ điều hành, phiên bản mới của Unix, dự án này tới nay vẫn chưa xác định là có thật hay không). Wow. Là 1 kẻ mọt sách nghiên cứu về hệ điều hành, tôi cảm thấy có chút lạ lẫm với định nghĩ trên, nhưng tôi chưa từng thấy Plan 9. Tôi biết rằng những đồn đoán về Plan 9 là để tập hợp lại và tạo nên Golang. Thật tuyệt vời khi các khán giả nhạc pop của họ không ngăn chúng không giải quyết các B-sides cũ. Tuy kì quặc nhưng chẳng có gì sai cả.
Tôi muốn kiểm tra 1 chức năng bất biến, làm thế nào để Go thực hiện các assertions? Hey, bạn 1 lập trình viên tôi. Đó chính là cách thực hiện. Các tác giả Go luôn cương quyết với các tài nguyên bị lạm dụng thường xuyên nên họ từ chối cung cấp các tài sản đó. Vì vậy, 1 số người sử dụng một hoặc một vài thư viện có thể chạy được.
Tôi đã tạo thử 1 phép đệ quy vô hạn và bị stack overflow (tràn stack). Go chỉ cho chạy 100 frames stack đầu tiên là hết. Bạn có thể thay đổi nó nhưng tôi không thể chỉ rõ cách thức để làm được điều đó (“Go Stackoverflow” là thứ vô dụng nhất mà bạn có thể tìm thấy, bạn có thể tìm kiếm lần lượt Go và Stackoverflow). Ai đó có thể thuyết phục tôi rằng tôi chỉ muốn 100 frame đầu chứ không phải cuối cùng, không phải 4 frame tương tự hết lần này đến lần khác. Cuối cùng tôi đã phải dùng đến thiết lập runtime.debug.SetMaxStack() để giới hạn số stack. Go đã thiết lập cho nó quá lớn để bắt được các frames phù hợp và quá nhỏ để thực thi các tác vụ bình thường
Tôi đã cố gắng sử dụng các công cụ khác (ahem, DTrace) để print stack nhưng dĩ nhiên là compiler Go bỏ qua các con trỏ đến các stack mà trình debugger không thể quan sát được. Lập luận Ditto dựa trên các quy ước gọi không đủ tiêu chuẩn ABI nhưng đó là chuyện khác. Môi trường thay đổi GOEXPERIMENT=framepointer phải tổng hợp với các con trỏ khung nhưng để rebuild toàn bộ thực sự là 1 thách thức. Tất cả các con đường như đang dẫn tôi đến câu kết luận gay gắt từ 1 đồng nghiệp cũ: Golang là rác rưởi.
Dù viết code bằng Golang có thú vị đi nữa thì debug bằng Golang lại chẳng có gì vui. Có thể vì tôi không biết công cụ phù hợp. Nhưng chắc chắc sẽ không có 1 debugger với khả năng Go build để compile, Go test để testing và Go run để chạy.
Non nớt và Tương lai hứa hẹn
Bạn đã từng ở trong 1 mối quan hệ mà những bất đồng nhỏ ngay lập tức leo thang thành “chúng ta nên chia tay đi?”. Tài liệu Go thậm chí có thể đẩy bạn sang ngôn ngữ khác mà không hề thấy sỉ nhục gì hết. Liệu tôi có các asserts không? Nếu bạn là 1 lập trình viên tồi thì đây là điều không cần bàn cãi.
Nhưng nếu tuân thủ theo ABI thì cũng có giá trị đấy chứ? Hãy tìm kiếm điều đó trong các ngôn ngữ khác. Bạn có thể cho tôi xem giá trị tuyệt đối của hàm int này? Bạn có gặp vấn đề gì với chìa khóa “ít hơn” của bạn không vậy?
Tôi chắc rằng thời gian sẽ, như nó vẫn hay làm, mang đến sự thực dụng. Tôi đánh giá cao việc Go thực sự nhận được những quan điểm tốt, mạnh mẽ (thật khó để nhớ được thời điểm mà tôi không đồng tình với chúng). Những quan điểm yếu kém đánh vào cách biến các ngôn ngữ thành mớ cơ chế hỗn độn, chồng chéo không thể đọc được. Ví dụ ưa thích của tôi với vấn đề này là Perl. Công việc lập trình đầu tiên của tôi là ở Perl. Tôi từng là độc giả tuổi teen tích cực của Perl llama và những quyển Camel. Trong lần phỏng vấn, Larry Wall – người sáng lập nên Perl – đã nói: “Trong Perl 6, chúng tôi đã quyết định rằng chỉnh sửa ngôn ngữ sẽ tốt hơn chỉnh sửa, thay đổi người dùng”. Tuyên bố này trái ngược với khẳng định của Go về assertions:
“Go không cung cấp các assertions. Không thể phủ nhận rằng các assertions này rất tiện lợi nhưng kinh nghiệm của chúng tôi cho thấy, các lập trình viên sử dụng chúng như vật chống đỡ để tránh phải suy nghĩ về report và giải quyết lỗi”
Bất cứ điều gì mà người dùng muốn, Perl sẽ trở thành chính thứ đó. Kẻ làm hài lòng người khác hết mức. Golang cho rằng người dùng có những thiếu sót và những cấu trúc của ngôn ngữ này sẽ chỉnh sửa những thiếu sót ấy. Đây là lập luận độc tài, kiên định trong chính lý tưởng của nó nhưng lại quá nhạy cảm để tìm kiếm sự thỏa hiệp (giống như bất kì ai mà chúng tôi đều biết?)
Dù có bực dọc đi nữa, tôi vẫn thích viết code bằng Go. Nó rõ ràng, sạch sẽ và được hỗ trợ bởi 1 cộng đồng và hệ sinh thái lớn. Tôi nhìn chung khá đau lòng khi Go 1.7 sẽ kết hợp mặc định với các frame pointers. Việc ước đoán 1 số loại bugs vẫn còn là vấn đề nhức nhối nhưng tôi tin chắc Go sẽ cải tiến và tôi sẽ nhận ra được nơi mà mình có thể bắt đầu làm việc.
( Dtrace)
Có thể bạn quan tâm:
Hiểu hơn về M-Commerce ( Mobile Electronic Commerce - thương ...
Các giai đoạn ứng dụng nền tảng điện toán di động (mobility) trong ...
Ứng dụng công nghệ di động vào giám sát phương tiện và đảm bảo ...
10 người Việt sẽ có 8 người dùng điện thoại di động
Sai lầm thường mắc phải khi phát triển ứng dụng di động
iOS bám đuổi quyết liệt Android về thị phần di động
5 lý do sở hữu một ứng dụng di động là cần thiết đối với doanh ...
Thiết bị di động chiếm 20% lưu lượng mua sắm trực tuyến
Tăng thêm 1% số người dùng di động sẽ đóng góp hơn 100 triệu ...
Kinh doanh nội dung số lấy di động làm 'kim chỉ nam'
Mã hóa giọng nói qua di động trở thành xu hướng mới
DVMS chuyên:
- Tư vấn, xây dựng, chuyển giao công nghệ Blockchain, mạng xã hội,...
- Tư vấn ứng dụng cho smartphone và máy tính bảng, tư vấn ứng dụng vận tải thông minh, thực tế ảo, game mobile,...
- Tư vấn các hệ thống theo mô hình kinh tế chia sẻ như Uber, Grab, ứng dụng giúp việc,...
- Xây dựng các giải pháp quản lý vận tải, quản lý xe công vụ, quản lý xe doanh nghiệp, phần mềm và ứng dụng logistics, kho vận, vé xe điện tử,...
- Tư vấn và xây dựng mạng xã hội, tư vấn giải pháp CNTT cho doanh nghiệp, startup,...
Vì sao chọn DVMS?
- DVMS nắm vững nhiều công nghệ phần mềm, mạng và viễn thông. Như Payment gateway, SMS gateway, GIS, VOIP, iOS, Android, Blackberry, Windows Phone, cloud computing,…
- DVMS có kinh nghiệm triển khai các hệ thống trên các nền tảng điện toán đám mây nổi tiếng như Google, Amazon, Microsoft,…
- DVMS có kinh nghiệm thực tế tư vấn, xây dựng, triển khai, chuyển giao, gia công các giải pháp phần mềm cho khách hàng Việt Nam, USA, Singapore, Germany, France, các tập đoàn của nước ngoài tại Việt Nam,…
Quý khách xem Hồ sơ năng lực của DVMS tại đây >>
Quý khách gửi yêu cầu tư vấn và báo giá tại đây >>
