Nhà sáng lập Zig nói thẳng sự thật, còn Anthropic thì đang khoác lác.

 (raymyers.org)
3 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong lúc Anthropic lấy sự cáo chung của kỹ nghệ phần mềm làm giá trị tương lai để chào bán, việc Bun chuyển từ Zig sang Rust cũng bị chỉ trích là đã bị tận dụng cho câu chuyện quảng bá rằng AI có thể thay thế công việc kỹ thuật
  • Bun nêu lỗi bộ nhớ làm lý do chuyển đổi, nhưng lại thiếu so sánh các phương án thay thế cùng ưu và nhược điểm, đồng thời không công bố những cái giá phải trả như thời gian biên dịch chậm của Rust, nên có thể bị xem là một sự hợp thức hóa sau khi việc đã rồi
  • Vẫn có những lựa chọn khác để vận hành Zig, và TigerStyle của TigerBeetle cho thấy một ví dụ ngăn lỗi use-after-free bằng cấp phát bộ nhớ tĩnh và kiểm thử mô phỏng
  • Cách chuyển từng tệp sang unsafe Rust là một hướng tiếp cận hợp lý giúp giảm rủi ro và mở đường cho tái thiết kế về sau, nhưng việc chấp nhận một cuộc chuyển đổi bằng AI ở quy mô hàng triệu dòng mã mà lại xem vài dòng mã quản lý con trỏ để con người đọc là vấn đề thì là một thái độ thiếu nhất quán
  • Vì vẫn cần agent harness, borrow checker của Rust, các quy tắc về khả năng đọc hiểu và khâu rà soát của con người, nên việc đưa coding agent vào sử dụng và việc khai tử kỹ nghệ phần mềm không phải là cùng một lựa chọn

Sự cáo chung của kỹ nghệ phần mềm mà Anthropic đang rao bán

  • Sau coding, Anthropic đang tích cực thúc đẩy câu chuyện rằng kỹ nghệ phần mềm, rồi đến phần lớn lao động của con người, sẽ biến mất
  • Công ty đã huy động được 132 tỷ USD vốn đầu tư và đang tiến gần đến một đợt IPO với định giá trên 1 nghìn tỷ USD, nhưng trong bối cảnh chưa thể chứng minh khả năng sinh lời, họ buộc phải bán ra ảnh hưởng giả định trong tương lai
  • Chính vì lợi ích như vậy, cần xem Anthropic như một người kể chuyện không đáng tin (unreliable narrator); điều quan trọng không chỉ là thông điệp đó đúng sai ra sao mà còn là nó ảnh hưởng thế nào đến phán đoán của ban điều hành, lãnh đạo thế giới và người quản lý quỹ hưu trí
  • Câu chuyện AI ảnh hưởng đến quyết định về kiến trúc, sản phẩm và bố trí nhân sự, đồng thời khiến việc giữ được phán đoán tỉnh táo trở nên khó khăn hơn giữa nỗi sợ sa thải, cảnh báo sẽ bị bỏ lại phía sau, và Doom Trolling
  • Khi đánh giá AI trong lĩnh vực phần mềm, cần có một cái nhìn hoài nghi có tính đến lợi ích và mục đích quảng bá của Anthropic

Việc Bun chuyển từ Zig sang Rust và lời giải thích muộn màng

  • Anthropic/Bun đã hợp nhất quyết định chuyển Bun viết bằng Zig sang Rust vào nhánh chính, rồi phải hai tháng sau mới đưa ra giải thích
    • Với một dự án hạ tầng quy mô lớn, việc giải thích định hướng từ trước thường là điều phổ biến hơn
    • Trong lúc lời giải thích còn đến muộn, các tiêu đề như Anthropic’s Bun Rust rewrite merged at speed of AI đã lan truyền ấn tượng rằng AI đã nhanh chóng hoàn tất việc viết lại
  • Andrew Kelley, nhà sáng lập Zig, đã công bố bài phản biện và với một giọng điệu thẳng thừng hiếm thấy, chỉ trích cả khía cạnh kỹ thuật lẫn cách vận hành tổ chức của Bun
    • Về mặt danh tiếng, điều này có rủi ro vì có thể thành tiền lệ rằng chỉ vì đổi ngôn ngữ mà người đứng đầu ngôn ngữ trước đó công kích cả khuyết điểm cá nhân
    • Có người gọi đây là một “meltdown”, nhưng cũng có thể xem là ông đã công khai chỉ ra những vấn đề cần phải được nói rõ

Tiêu chí để đánh giá một lời chỉ trích thẳng thừng

  • Chánh ngữ (right speech) trong Phật giáo cho rằng mọi phát ngôn đều phải đáp ứng năm tiêu chí sau
    • Có đúng sự thật không
    • Có hữu ích không
    • Có đúng thời điểm không
    • Có tử tế không
    • Có xuất phát từ lòng tử tế không
  • Phản ứng của Andrew Kelley thuộc dạng lời nói đúng nhưng thiếu tử tế, và điểm gây tranh luận là liệu việc công khai chỉ ra vấn đề như vậy có cần thiết hay không, dù có vượt ra ngoài phép lịch sự thông thường

Mối quan hệ giữa Bun, Zig và chính sách đóng góp bằng AI

  • Bun là một runtime TypeScript thường được ví như NodeJS nhanh hơn, còn Zig là một ngôn ngữ lập trình hệ thống thường được ví như C hiện đại
  • Cho đến gần đây, Bun được viết bằng Zig và là một trong những codebase Zig lớn nhất
  • Chính sách đóng góp bằng AI của hai dự án này hoàn toàn trái ngược
  • Sau khi Anthropic mua lại Bun, nhà sáng lập Jarred Sumner đã tiến hành một thử nghiệm agent quy mô lớn để chuyển mã Zig sang unsafe Rust, và kết quả được hợp nhất chỉ sau vài ngày rồi trở thành phiên bản chính thức
  • Trong số các bên liên quan, có vẻ không ai tiếp tục yêu cầu phải giữ Bun ở Zig, và tranh luận tập trung không phải vào bản thân việc chuyển đổi mà vào lý do và cách nó được quảng bá
  • Việc dùng agent để thực hiện chuyển đổi ngôn ngữ ở quy mô lớn vẫn là một thử nghiệm kỹ thuật đáng để thử lại, nếu đặt trong hoàn cảnh phù hợp

Ba cách diễn giải quanh cùng một quyết định

  • Với những nhà phát triển đang cân nhắc chọn Zig hay Rust, việc một trong những người dùng Zig lớn nhất đảo ngược quyết định là dữ liệu đánh giá quan trọng
  • Cách diễn giải của Anthropic/Bun là họ đã thử mọi biện pháp hợp lý nhưng vẫn khó kiểm soát lỗi bộ nhớ khi dùng Zig
  • Theo cách diễn giải của Andrew Kelley, codebase của Bun trở nên rối nát là do các quyết định kỹ thuật của chính Bun, chẳng hạn như giao quá nhiều việc viết mã và review cho AI agent
  • Một khả năng bình thường hơn là các vấn đề bộ nhớ thực sự có nhiều cách giải quyết, nhưng ban điều hành thấy việc viết lại bằng Rust dễ được chọn hơn
    • Có thể quảng bá năng lực của mô hình Fable mới
    • Anthropic vốn đã dùng Rust
    • Dự án Zig công khai phản đối việc sử dụng sản phẩm của Anthropic
  • Việc chuyển sang Rust có thể hợp lý về mặt kinh doanh, nhưng phần quảng bá lại tập trung vào việc AI đủ mạnh để thực hiện cuộc viết lại
    • Việc AI đã không phát hiện trước lỗi use-after-free lại mâu thuẫn với chính câu chuyện này
  • Sự cường điệu qua chiếc loa phóng thanh của Anthropic khiến người ta đem phán đoán của Jarred Sumner và Andrew Kelley ra so trực tiếp, đồng thời vô tình cũng có thể ảnh hưởng đến danh tiếng của Zig

Vì sao độ tin cậy cá nhân lại đi vào tranh luận kỹ thuật

  • Chủ thể cần bị truy trách nhiệm trước hết không phải cá nhân nhà sáng lập Bun mà là Anthropic, bên đang tận dụng sự việc này cho câu chuyện AI của mình
  • Vì Anthropic đang dùng độ tin cậy của Jarred Sumner để củng cố thông điệp của họ, nên để phản hồi lại, người ta buộc phải đánh giá cả phán đoán và hành động của anh ấy
  • Sẽ tốt hơn nếu chỉ bàn về vấn đề kỹ thuật, nhưng khi thông điệp của Anthropic dựa vào sự giật gân và quảng bá nhiều hơn là so sánh kỹ thuật, thì độ tin cậy cá nhân cũng bị kéo vào cuộc tranh luận
  • Nếu chỉ cần tổng hợp lại những lời nói và hành động mà chính đương sự đã công khai cũng đã khiến nó trông như bôi nhọ, thì có thể chính những hành động đó cũng là một phần của vấn đề

Crunch kéo dài liên miên và môi trường tổ chức của Bun

  • Thông báo tuyển dụng năm 2022 của Bun cảnh báo rằng 9 tháng đầu sẽ cực kỳ vất vả, và nếu coi trọng kiểu cân bằng công việc-cuộc sống với nhiều thời gian không làm việc thì đây sẽ không phải nơi phù hợp
  • Trạng thái crunch mode thường trực gây hại cho cả sức khỏe lẫn năng suất, điều đã được xác nhận lặp đi lặp lại trong các nghiên cứu thực nghiệm về lao động tri thức
  • Thay vì một quản lý khoe làm việc 90 giờ mỗi tuần, nên chọn một quản lý biết bảo vệ để nhân viên còn có thể ngủ vào ban đêm
  • Đánh giá mà Andrew Kelley nói là ông nghe từ người liên quan trong đội Bun có thể được tóm lại là thiếu giao tiếp, kỳ vọng phi thực tế, ít đồng cảm và thiếu kinh nghiệm, nhưng bị giới hạn bởi tính chất truyền miệng
  • Tuy vậy, đánh giá này cũng phù hợp với môi trường làm việc cực đoan mà Bun đã công khai trong thông báo tuyển dụng
  • Ngay cả trong môi trường làm việc tệ, công nghệ xuất sắc vẫn có thể ra đời, và bản thân Bun vẫn là một công cụ hữu dụng và thú vị
  • Nhận định rằng mã nguồn có nhiều lỗi và khó bảo trì không chỉ là phê bình từ bên ngoài, mà còn là chính trạng thái mà Bun đã viện dẫn làm căn cứ cho việc chuyển sang Rust

Giá trị thực tiễn của cách chuyển sang unsafe Rust

  • Các chi tiết kỹ thuật trong quá trình chuyển đổi cũng đáng để tái sử dụng cho những dự án hiện đại hóa khác
  • Bun đã thực hiện chuyển đổi theo từng tệp sang unsafe Rust thay vì thiết kế lại bằng Rust an toàn ngay từ đầu
    • Giữ nguyên cấu trúc hiện có để giảm rủi ro ở giai đoạn chuyển đổi ban đầu
    • Đồng thời tạo nền tảng để sau này cải thiện độ an toàn và thiết kế lại
  • Tự động hóa dựa trên AI có thể khiến việc đảo ngược lựa chọn ngôn ngữ trở nên dễ dàng hơn trước, nhưng việc viết lại tự động vẫn còn ưu nhược điểm và khác biệt về ngữ nghĩa
  • Cũng có thể kết hợp nhiều kỹ thuật viết lại và tăng cường bằng các phương pháp hình thức (Formal Methods)
  • TRACTOR của DARPA là chương trình nghiên cứu chuyển toàn bộ mã C sang Rust, và báo cáo đánh giá được công bố công khai đề cập đến hiện trạng của công nghệ chuyển đổi tự động
  • Dù các tác nhân có thể mang lại nhiều lựa chọn hơn cho mã cũ, việc xác định mục tiêu hiện đại hóa vẫn tiếp tục đòi hỏi phán đoán và giao tiếp

Tài liệu ra quyết định kỹ thuật còn thiếu nhiều thứ

  • Để giải thích một quyết định kỹ thuật, tối thiểu cần ba yếu tố
    • Động cơ là gì
    • Đã xem xét những phương án thay thế nào
    • Ưu và nhược điểm của từng phương án là gì
  • Tài liệu tổng hợp lý do Richard Feldman chuyển trình biên dịch Roc từ Rust sang Zig là một trường hợp đối chiếu có đủ cả ba yếu tố
  • Phần giải thích của Bun có nêu động cơ là lỗi bộ nhớ, nhưng chỉ đề cập một phần các phương án thay thế đã xem xét, và gần như bỏ trống phần so sánh ưu nhược điểm
  • Đặc biệt, khi lược bỏ ưu nhược điểm, nó có thể trông như một kiểu hợp thức hóa sau quyết định, tức là chốt sẵn đáp án rồi mới gắn lý lẽ vào sau
  • Cũng không thể loại trừ khả năng tồn tại những lý do riêng chưa công khai; để tăng độ tin cậy của quyết định thì cần công bố cả những chi phí bất lợi đi kèm

So sánh chỉ liệt kê ưu điểm của Rust

  • Phần “Bun is better in Rust” chỉ nói về lợi ích của việc chuyển sang Rust và hầu như không nêu chi phí
  • Các codebase Rust lớn thường đánh đổi bằng thời gian biên dịch chậm để lấy độ an toàn
  • Trước đây Bun từng coi trọng tốc độ biên dịch đến mức fork trình biên dịch Zig để cải thiện gấp 4 lần
  • Nếu việc chuyển sang Rust làm tăng thời gian build của người đóng góp, thì cần công khai điều đó và giải thích vì sao độ an toàn quan trọng hơn chi phí ấy; như vậy quyết định mới đáng tin hơn
  • Những cải tiến khác đạt được sau khi chuyển đổi cũng có thể bị trộn vào danh sách ưu điểm của việc viết lại bằng Rust, khiến tác động trực tiếp của việc đổi ngôn ngữ bị phóng đại

Lựa chọn style guide chưa được xem xét

  • Ở Bun, lỗi bộ nhớ không phải nguyên nhân lỗi duy nhất, nhưng theo thống kê cá nhân thì chúng xảy ra đủ thường xuyên để cần tới 4 commit sửa lỗi mỗi tuần
  • Mỗi lỗi bộ nhớ đều có nghĩa là quy ước nào đó về cách tạo, sở hữu và giải phóng đối tượng đã bị phá vỡ ở đâu đó, nên trước hết có thể xem xét cách xác định rõ hành vi kỳ vọng trong từng tình huống
  • Quản lý bộ nhớ thủ công làm mở rộng phạm vi của các quy ước, nhưng dù dùng ngôn ngữ nào cũng cần hướng dẫn sử dụng hiệu quả; ngay cả Rust cũng có API style guide

  • Phương án thay thế mà TigerBeetle cho thấy

    • TigerBeetle, một codebase Zig tiêu biểu khác là cơ sở dữ liệu giao dịch tài chính, không bị hành hạ bởi lỗi bộ nhớ và có vẻ là một trong những cơ sở dữ liệu đáng tin cậy nhất
    • Nó lấy TigerStyle và kiểm thử mô phỏng làm nền tảng cho độ tin cậy
    • TigerStyle không chỉ là một quy ước viết mã đơn thuần mà là một triết lý kỹ thuật gắn kết thiết kế, bộ nhớ và kiểm thử
    • Toàn bộ bộ nhớ được cấp phát tĩnh ngay khi khởi động
    • Sau khi khởi tạo, không cho phép cấp phát động hay cấp phát lại sau khi giải phóng
    • Điều đó ngăn lỗi use-after-free đồng thời tránh các biến động hiệu năng khó dự đoán
    • Nó buộc phải tính đến các mẫu sử dụng bộ nhớ có thể xảy ra ngay từ giai đoạn thiết kế, từ đó dẫn tới cấu trúc đơn giản hơn, nhanh hơn, và dễ suy luận cũng như bảo trì hơn
    • Không phải mọi ứng dụng đều có thể áp dụng nguyên xi cách này, nhưng nó cho thấy chính sách bộ nhớ gắn liền với các quyết định thiết kế tổng thể

  • Những khoảng trống còn lại trong phần giải thích của Bun

    • Bun nhắc đến TigerStyle và style guide C++ dài 31.000 từ của Google, rồi kết luận rằng style guide khó cưỡng chế và theo truyền thống phải dựa vào review code, linter và công cụ phân tích tĩnh
    • Tuy nhiên, Bun không đề cập họ thực sự đã dùng style guide nào, vì sao nó thất bại, và đã cải thiện thế nào trong suốt 4 năm
    • Nếu các vấn đề bộ nhớ vẫn kéo dài trong một dự án lớn, thì điều quan trọng là liệu những phương án dùng ngôn ngữ hiện tại theo cách khác có được thử nghiệm nghiêm túc hay không, nhưng bằng chứng hậu thuẫn cho điều đó còn thiếu
    • Cách vận hành mà một người giữ toàn bộ bối cảnh trong đầu và không họp hành khiến việc tạo ra các quy ước rõ ràng và thiết kế được chia sẻ trở nên khó khăn

Mâu thuẫn giữa review bằng tác nhân và style guide

  • Bun cho rằng style guide khó cưỡng chế, nhưng đồng thời nói rằng họ đã viết PORTING.md cho việc migration và để các tác nhân review toàn bộ mã viết lại theo những chỉ dẫn nghiêm ngặt
  • Bản thân PORTING.md đã là một style guide chuyên biệt cho phạm vi chuyển đổi, nên nếu review bằng tác nhân thành công thì có nghĩa là bài toán cưỡng chế chỉ dẫn thực ra đã được giải quyết
  • Trong những điều kiện phù hợp, review bằng tác nhân có thể hoạt động, nhưng tiền đề là phải có quy tắc và phương thức review được thiết kế đầy đủ
  • Cùng lượng nỗ lực về mặt tư duy đó cũng có thể được dùng để tái thiết kế mã Zig và siết chặt quy ước, nhưng Bun đã chọn viết lại thay vì tái kiến trúc
  • Việc viết lại có thể đã là lựa chọn đúng vì nhiều lý do chưa được công khai, nhưng chỉ với phần giải thích hiện tại thì việc so sánh các phương án thay thế vẫn chưa đầy đủ

Viết lại một triệu dòng và ba dòng mã con trỏ

  • Bun cho rằng để bộc lộ kỳ vọng về quyền sở hữu ở cấp độ kiểu trong Zig thì cần thêm mã như SharedPtr(TCPSocket) và deref(), kém tiện hơn so với cách dùng con trỏ hiện có
  • Trong ví dụ này, để làm rõ việc truyền con trỏ ở ranh giới giao diện thì số mã tăng thêm cỡ ba dòng
  • Việc chấp nhận một PR do AI tạo ra ở quy mô cả triệu dòng vốn rất khó review, nhưng lại bác bỏ vài dòng làm rõ quyền sở hữu con trỏ vì lý do khả năng đọc, là một thái độ thiếu nhất quán
  • Jarred Sumner từng nói rõ rằng trong nhiều tháng qua con người không trực tiếp gõ mã
  • Nếu mã không còn là để phục vụ con người, thì lý do cho rằng wrapper SharedPtr khó nhìn sẽ yếu đi; còn nếu vẫn là để phục vụ con người thì vẫn phải tiếp tục cân nhắc khả năng đọc, khả năng review và khả năng bảo trì
  • Các công ty AI ngại thừa nhận rằng tính dễ đọc của mã vẫn quan trọng, nhưng nếu phủ nhận điều đó thì tuy hợp với câu chuyện “kỹ nghệ phần mềm đã kết thúc”, nó lại mâu thuẫn với thực tế bảo trì
  • Cũng đã có benchmark cho thấy các coding agent về cơ bản có thể làm xấu đi khả năng bảo trì

Cùng một sự kiện cho thấy rằng ‘chỉ AI thôi là chưa đủ’

  • Việc Bun tái viết tác tử ở quy mô lớn không chỉ phục vụ cải thiện kỹ thuật mà còn thực hiện vai trò kinh doanh là quảng bá thông điệp của Anthropic rằng “chỉ cần AI là đủ”
  • Tuy nhiên, chính ví dụ đó cũng có thể được diễn giải theo hướng hoàn toàn ngược lại
  • Dựa trên giả định rằng ngay cả những vấn đề do agent tạo ra cũng có thể được giải quyết bằng nhiều agent hơn, xu hướng mua token thay vì công cụ tốt hơn và gắn SKILL.md thay vì học kỹ năng đang lan rộng
  • Việc gọi các phiên song song của agent là Team thay vì hiểu tâm lý của các nhóm phần mềm là đang nhầm lẫn giữa tổ chức con người và các phiên chạy tự động

Việc đưa coding agent vào sử dụng và việc vứt bỏ engineering là hai chuyện khác nhau

  • Chiến dịch tuyên truyền về sự cáo chung của software engineering của Anthropic có thể gây phản tác dụng cho cả bên làm ra lẫn bên sử dụng công cụ AI
  • Dù có đưa coding agent vào sử dụng, cũng không cần coi Dark Software Factory — nơi con người không hiểu mã — là mô hình lý tưởng
  • Mục tiêu là tạo ra thứ con người thực sự muốn và làm cho nó hoạt động đúng, trong khi bong bóng AI có thể gây áp lực phải làm ra những thứ không ai muốn với chất lượng thấp
  • Cần một hướng đi tận dụng AI nhưng không từ bỏ phán đoán, học hỏi, giao tiếp, tính dễ đọc và khả năng bảo trì

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Bài này có nhiều ý hay, nhưng nó làm tôi nghĩ đến các dự án do AI tạo ra rồi bị bỏ đi chỉ sau vài tháng. Giá trị của một dự án nằm ở mức độ đã được kiểm chứng trong thực tế, chứ không phải lượng mã được sinh ra; và mã nguồn hiện có đã trưởng thành thì tốt hơn một bản viết lại mới
    Codebase Zig hiện tại đã được kiểm chứng, nhưng bản viết lại bằng Rust thì ngoài việc vượt qua test ra gần như có mức độ kiểm chứng bằng 0; và nếu đã dịch sát từng file bằng unsafe Rust thì cũng không rõ nó tốt hơn điểm xuất phát là Zig ở chỗ nào. Chỉ sau khi tiếp tục chuyển sang Rust an toàn và được kiểm chứng trong môi trường vận hành cùng nhiều người dùng thì nó mới thật sự có ý nghĩa
    Về thực chất thì đây gần như là một nhánh fork của Bun, nên dù bản Zig hay bản Rust tồn tại cũng không quan trọng, và cũng không có lý do gì để xem chuyện này là vấn đề về độ phù hợp của Zig

    • Các dự án AI bị bỏ đi vì chúng được tạo ra một cách ngẫu hứng. Chi phí chìm ngược lại đôi khi lại là một lợi thế giúp con người vượt qua nghịch cảnh và giai đoạn trì trệ, nhưng với một sản phẩm chỉ được tạo từ ý tưởng bộc phát và vài prompt Claude thì chẳng ai gắn bó với nó
      Ngay cả tôi, một lập trình viên bình thường, cũng nghĩ ra hàng chục ý tưởng hay mỗi ngày, nhưng chỉ rất ít trong số đó chịu được quá trình xem xét kỹ lưỡng, và vài ngày sau ngay cả những ý tưởng ấy cũng trông không còn đáng để bỏ công. Ý tưởng vốn đã rẻ, giờ đến cả proof of concept cũng rẻ, nên tôi không hứng thú với những Show HN còn chưa được đầu tư nổi một tháng
    • Muốn đạt tới Rust an toàn đã được kiểm chứng đáng kể trong thực tế thì phải bắt đầu từ đâu đó, nên trước mắt họ dịch sát rồi cải thiện dần
      Có vẻ phe Zig lo rằng Zig ngay từ đầu đã là một ngôn ngữ không có nhiều triển vọng, vì nó không đem lại đủ lợi thế so với C để được dùng cho mục đích nghiêm túc, đến mức ngay cả dự án tiêu biểu cũng rời đi. Chỉ cần tìm segfault trong trình theo dõi issue của Zig là sẽ hiểu vì sao người ta nghi ngờ giá trị tương lai của nó trước các lựa chọn thay thế như Rust
    • Khác với Zig, giờ đây đã có ranh giới unsafe rõ ràng và giới hạn phạm vi, và điều đó tốt hơn vì có thể sửa từng phần một
    • Phần mở đầu của bài viết quá cay nghiệt. Nhìn vào những người quen của tôi ở Anthropic và OpenAI, họ thực sự tin rằng trong tương lai gần agent sẽ đảm nhận phần lớn việc lập trình và chính họ cũng sẽ mất việc
      Đây không phải là chuyện kiểm soát thông điệp để dạy dỗ phe phản AI
    • Không thể khẳng định lý do các dự án do AI tạo ra bị bỏ nhanh là vì thiếu kiểm chứng thực tế. Các dự án cá nhân thông thường cũng đa số bị bỏ sau một thời gian, và có thể là vì khi giờ đây người ta viết code nhanh hơn rất nhiều, họ cũng đạt tới điểm giảm dần của lợi ích cận biên về giá trị cá nhân, học hỏi và niềm vui sớm hơn

  • Vấn đề lớn hơn việc Andrew nói thẳng là thái độ hai mặt của bài viết: rõ ràng là công kích cá nhân nhưng lại khăng khăng nói không phải
    Đọc xong bài này, tôi không còn muốn xây gì đó bằng Zig nữa. Dù bạn đưa ra quyết định kỹ thuật nào đi nữa, BDFL suốt đời đầy nhân từ của Zig vẫn có thể viết ra kiểu bài như thế; và thật khó tưởng tượng ban lãnh đạo của các cộng đồng khác như Python hay Rust lại hành xử như vậy

    • Điều nghiêm trọng hơn là dường như thái độ này đang lan sang cộng đồng Zig. Dù hiện tại chưa phải số đông, nhưng nếu những người tử tế rời đi để tìm cộng đồng ấm áp hơn thì tỷ trọng kiểu tính cách này trong nhóm còn lại sẽ tăng lên
    • Tôi muốn bênh Andrew ở chỗ ông ấy thật lòng coi trọng việc làm điều đúng đắn nên có quan điểm mạnh mẽ, nhưng lại là người kiên nhẫn và bao dung hơn nhiều so với những gì người ngoài có thể phán đoán
      Có người sẽ thấy Andrew đã tấn công Bun, còn tôi lại có thể xem phản ứng nhắm vào Andrew là công kích cá nhân. Nếu gạt bỏ thành kiến, có lẽ phải nhìn nhận rằng cả hai bên đều sai, hoặc chẳng bên nào sai; và khi đánh giá một tình huống từ xa, ta nên ý thức rằng thành kiến cá nhân ảnh hưởng quá lớn
    • Nếu rời đi mà không viết những bài dễ gây hiểu lầm khiến Zig trông xấu đi, và không vắng mặt không báo trước ở các cuộc họp đã hẹn với quỹ Zig, thì mọi chuyện đã ổn
    • Bài của Andrew đã được chỉnh sửa nhiều lần, nên nếu đọc bản sửa đổi mới nhất thì có thể những lo ngại đó sẽ được giải tỏa: https://github.com/andrewrk/andrewkelley.me/commits/master/p...
    • Rust về thiết kế không có BDFL, và theo tôi nhớ thì Python cũng đã rời khỏi mô hình này. Một cá nhân đóng góp có thể nổi giận và viết bài công kích, nhưng không có một con người duy nhất đại diện cho cả ngôn ngữ như Zig

  • Tôi muốn đứng về phía Andrew. Với tư cách người đã theo dõi công việc của Sumner suốt nhiều năm, tôi thấy phê bình của Kelley dù thiếu thiện chí nhưng phần lớn là sự thật, và dù kết quả có hữu ích và ấn tượng đến đâu thì từ đầu đến cuối nó vẫn gần với một màn gây ảnh hưởng để tự quảng bá hơn
    Bản thân tôi cũng làm phát triển dựa trên agent 8 tiếng mỗi ngày và đã khuyên đội của mình dùng Rust và Deno thay vì Node, nhưng bản viết lại này có cơ sở biện minh quá yếu và trông như phần nối dài của chiến dịch quảng bá dài hơi mà Dario và cộng sự đã thúc đẩy thành công. Nếu cách diễn đạt mềm hơn thì có lẽ đã được đón nhận tốt, nhưng tôi vẫn đánh giá cao việc ông ấy đưa ra suy nghĩ thật lòng thay vì một bài do đội PR chắp bút

    • Bài học rút ra từ vụ ồn ào này là trước khi đăng một câu trả lời quá gay gắt, ta nên để đó 1–2 ngày rồi đưa cho bạn thân xem. Sẽ tốt hơn nếu ngay từ bản sửa đầu tiên Andrew đã viết phần kết giống như bản ông ấy sửa về sau
    • Việc biện minh trước cho bản viết lại là khá yếu, nhưng tôi vẫn hiểu vì sao Jarred cảm thấy bực bội, kể cả khi không có ví dụ cụ thể
      Phần giải thích rằng Bun có những khó khăn riêng do phải tương tác với bộ gom rác của JavaScript là hữu ích, nhưng Andrew hoàn toàn không đả động tới. Còn phần nói mã mới đã được kiểm chứng bằng bộ test hiện có cũng giúp xóa đi hiểu lầm rằng ngay cả test cũng đã bị dịch kiểu vibe coding nên không thể tin được. Việc test không bắt được mọi lỗi là điều đúng với mọi phần mềm, kể cả Zig
      Rốt cuộc, chuyện này lan rộng vì sự va chạm giữa quan điểm ngôn ngữ không an toàn bộ nhớ tạo ra chi phí lỗi khổng lồ với phản ứng kiểu “hãy nâng cao tay nghề để đừng viết bug”, rồi được khuếch đại thêm bởi tranh luận về AI, sự tham gia của Anthropic và cách nói chuyện kiểu Linus của Andrew
    • Cách nghĩ rằng phải biện minh cho một bản viết lại với người ngoài công ty tự nó đã là điều kỳ lạ
    • Trong các vấn đề kỹ thuật, tôi thích thái độ nói thẳng sự thật như Linus hơn là lời lẽ mang tính PR; kiểu diễn đạt quảng bá chỉ nên dùng với khách hàng không chuyên kỹ thuật

  • Tôi nghi ngờ liệu hai bài viết của Anthropic và Andrew Kelley có được đọc theo cùng một cách hay không. Anthropic không phải là công ty bán ngôn ngữ lập trình, và bài viết về việc Bun viết lại bằng Rust có nhiều chi tiết kỹ thuật cho thấy sản phẩm đã được cải thiện thế nào đối với người dùng cuối
    Trong khi đó, phản hồi từ phía Zig gần giống một bài xã luận cay độc đầy công kích cá nhân hơn. Tôi dùng Codex và không có lợi ích gắn với cả Zig lẫn Rust, nên đang quan sát từ bên ngoài

    • Anthropic rõ ràng cũng có lợi ích trong thị trường ngôn ngữ lập trình. Nếu AI khiến việc viết lại sang một ngôn ngữ cụ thể trở nên dễ dàng, thì các câu chuyện thành công sẽ gắn ngôn ngữ đó với công ty AI, và thành công của Rust như một ngôn ngữ dễ viết bằng AI cũng có lợi cho Anthropic
      Ngoài ra, khi quảng bá một ca viết lại thành công, người ta thường che đi những yếu tố bất lợi cho câu chuyện, như việc mã hiện có đã tệ đến mức nào, và lần này cũng đã bỏ sót những khía cạnh quan trọng
      Bài viết của Andrew Kelley(https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...) đề cập đến tiêu chuẩn kỹ thuật thấp của Jarred, quan hệ đối ngoại yếu kém như việc vắng mặt trong các cuộc họp với Zig Foundation mà không báo trước, thiệt hại phát sinh khi mô tả Zig là một lựa chọn tồi trong quá trình chuyển sang Rust, và sự phẫn nộ của ZSF vì điều đó
      Nếu chỉ nhìn lướt qua thì có thể lo rằng nhà sáng lập ngôn ngữ đang công kích một người dùng cũ, nhưng Kelley đã giải thích vì sao ấn tượng đó — cũng là ấn tượng tôi từng có khi chỉ đọc bài của Bun — là không công bằng. Một số công kích cá nhân rõ ràng là có thật, và phần cuối được thêm vào sau đó cũng đề cập điều này
    • Hãy thử tưởng tượng một studio chuyển từ Unity sang Unreal, rồi Unity đăng một bài công kích chất lượng mã và môi trường làm việc trước đây của studio đó, thì bản thân việc Zig phản hồi như vậy đã là điều kỳ lạ
    • Đây là xung đột lâu đời giữa chủ nghĩa thủ công và chủ nghĩa công nghiệp. Andrew thuộc về truyền thống muốn mọi nhà phát triển đều là những người thợ lành nghề đầy tự hào
      Java, JavaScript, Python và C# đã thống trị ngành công nghiệp lấy C++ làm trung tâm bằng cách cung cấp các cơ chế an toàn để ngay cả những lập trình viên không theo chủ nghĩa hoàn hảo cũng có thể làm việc mà không gây ra sự cố lớn. C và C++ có lợi thế hiệu năng lớn, nhưng đòi hỏi tay nghề đáng kể trong một môi trường ngày càng khắc nghiệt
      Rust và Swift mang lại khả năng dự đoán hiệu năng cao hơn ngôn ngữ có garbage collection, đồng thời cung cấp mức an toàn tương đương hoặc mạnh hơn, và các ý tưởng của Rust đã khiến những ngôn ngữ mới trong lĩnh vực này bùng nổ. Tuy vậy, khá nhiều trong số đó gần với chủ nghĩa thủ công hơn Rust, vốn xuất phát từ nhu cầu công nghiệp
      Nếu ví với xe cộ thì Java, JavaScript v.v. là xe an toàn thông thường, C/C++ là mô tô hai bánh, Rust là xe rally nhanh nhưng bảo vệ người ngồi bên trong, còn Zig giống mô tô bốn bánh hoặc xe kart bánh hở hơn. Nó có thể không dễ trượt, nhưng nếu lật thì rất nguy hiểm
      Những người theo chủ nghĩa thủ công, bỏ qua ràng buộc thời gian và chi phí, cho rằng chỉ cần các lập trình viên cẩn thận là đủ; nhưng trong môi trường công nghiệp, dù có thể viết mã tốt thì 90% công việc vẫn diễn ra dưới ràng buộc, nên khó mà tin được cả mã của mình lẫn của người khác. Zig có nhiều ưu điểm, nhưng ngay từ đầu đã là ngôn ngữ dành cho những người thích tự do hack hơn là an toàn
    • Việc cải thiện kích thước nhị phân và tốc độ không liên quan nhiều đến bản thân chuyện viết lại bằng Rust, và có lẽ cũng đạt được nếu đầu tư nỗ lực tương tự vào codebase Zig. Có phần như đã làm thêm việc để các con số này trông đẹp hơn nhằm quảng bá cho cuộc viết lại
      Về an toàn bộ nhớ, nếu thay vì AI, test và fuzzing cấp cao hơn mà dùng fuzzer tích hợp do nhóm Zig khuyến nghị, thì có lẽ cũng đạt được mức tương tự. Dù vậy, với một dự án như Bun thì Rust trưởng thành hơn có thể vẫn là lựa chọn tốt
      Góc nhìn của Andrew là thiết yếu để hiểu chuyện gì đã xảy ra. Một số cách diễn đạt có thể mềm hơn, nhưng nếu quản lý tồi là nguyên nhân trực tiếp của quan hệ xấu đi và kết quả kỹ thuật kém, thì nêu rõ điều đó không phải công kích cá nhân mà là bối cảnh cần thiết
    • Xem một sản phẩm giúp tăng năng suất lập trình viên bằng cách viết mã thay họ là không liên quan đến thị trường ngôn ngữ chỉ vì nó không bán ngôn ngữ riêng của mình là quá thiển cận
      Đặc biệt là khi ban lãnh đạo Zig công khai không thích vibe coding và chỉ trích ngành này, còn dự án thì từ chối các pull request được tạo bằng sản phẩm đó

  • Cuộc tranh cãi này lại thiếu nội dung kỹ thuật thực chất. Tôi không quan tâm đến việc Bun chuyển sang Rust, bài viết công kích của Andrew, hay Anthropic như kẻ bán xẻng trong cơn sốt vàng; tôi muốn xem nội dung kỹ thuật cụ thể
    Động cơ Jarred đưa ra cho việc chuyển sang Rust có vẻ hợp lý dù cơ sở có phần yếu, nhưng Andrew không phản biện vì sao đó không phải vấn đề thực sự hoặc trong Zig thì nên giải quyết một cách bài bản ra sao. Tôi đặc biệt muốn thấy phân tích dựa trên chính mã Zig thực tế của Bun

    • Chỉ nhìn vào các dữ kiện phía Bun đưa ra thì tính chính đáng về mặt kỹ thuật của việc viết lại là yếu, và điều đó không có gì đáng ngạc nhiên vì trong đa số trường hợp viết lại là kỹ thuật tồi
      Bun được khởi đầu bởi một người thiếu kinh nghiệm với Zig, bất chấp phạm vi và độ phức tạp rất lớn, và ngay từ đầu đã là dự án viết lại mã từ một ngôn ngữ khác. Nếu bộ chuyển đổi JavaScript·TypeScript của esbuild đã được chuyển từng dòng từ Go sang Zig rồi vài năm sau toàn bộ codebase lại bị bỏ để viết lại bằng một ngôn ngữ khác, thì tôi không rõ còn gì để bàn thêm
    • Ý chính của Andrew là mã Bun vốn đã tệ từ đầu, và tôi hiểu như ông ấy cũng ngầm cho rằng Jarred là một nhân vật độc hại nên cuộc tranh luận này không đáng để tham gia
    • Bun muốn di chuyển nhanh và phá vỡ mọi thứ, còn Zig buộc người ta phải đi chậm và cẩn trọng
      Bun muốn phát hành các tính năng như ngôn ngữ shell, client SQLite/PostgreSQL nhanh nhất có thể nên không muốn phải tự lo trực tiếp việc quản lý bộ nhớ. Zig buộc lập trình viên phải tự xử lý quản lý bộ nhớ và vòng đời, cố ý không thêm những tính năng như Drop, trong khi Rust nhờ có Drop nên phù hợp hơn
      Cũng như người ta không xây dựng cơ sở dữ liệu SQL bằng Python, Zig không phải công cụ phù hợp cho Bun, và đây không hẳn là vấn đề cần giải quyết theo chính thống trong Zig mà là khác biệt trong cách Jarred muốn đẩy dự án tiến nhanh
    • Bài gốc có đề cập trực tiếp đến vấn đề này nhưng gần như chỉ chọn những mặt tốt. Chẳng hạn, họ nói đã viết lại cả trình biên dịch Zig để cải thiện thời gian build, nhưng tại sao lại hoàn toàn không đả động đến thời gian build của Rust, vốn thường chậm hơn rất nhiều?
    • Kẻ bán xẻng trong cơn sốt vàng là các công ty làm trung tâm dữ liệu và năng lượng, còn token mới là vàng

  • Tôi đồng ý với một số quan điểm của Kelley, nhưng vấn đề là giọng điệu
    Nếu Bun được viết lại từ Rust sang Zig, khó có khả năng một thành viên nòng cốt của nhóm Rust sẽ viết một bài công kích cá nhân nhắm vào Sumner rồi khẳng định đó không phải là công kích. Kelley có quyền viết bài ông ấy muốn, nhưng mọi người cũng có quyền phản ứng với hình ảnh công khai của Zig do BDFL của một ngôn ngữ đang phát triển tạo ra

  • Bài viết về việc Bun chuyển sang Rust đã bỏ qua phần so sánh các lựa chọn cụ thể và các số liệu tác động, đồng thời trình bày kết quả theo hướng thiên lệch, nên không mang cảm giác của một bài blog kỹ thuật
    Có vẻ mọi người quan tâm đến việc dùng agent hơn là cơ sở kỹ thuật của việc port, và xét về mặt kỹ thuật thì điều này rất đáng thất vọng

    • Tôi nghi ngờ là chúng ta có đọc cùng một bài không. Dù không đi vào từng dòng mã cụ thể, bài đó vẫn lặp đi lặp lại các chi tiết kiến trúc sâu, căn cứ về an toàn bộ nhớ và lỗi, cùng các mẫu coding bằng agent ở quy mô lớn

  • Không nên đánh giá thấp sức ảnh hưởng của marketing đối với ban quản lý và giới điều hành, đặc biệt là việc những người ở vị trí như CEO có thể bị chi phối bởi những cảm xúc rất nhỏ nhặt đến mức nào
    Chỉ riêng việc đây là một cơ hội để quảng bá mô hình Fable mới và việc Zig công khai phản đối việc sử dụng sản phẩm Anthropic cũng có thể đã khiến quyết định viết lại Bun bằng Rust gần như được định sẵn

    • Tôi không hiểu vì sao lại cho rằng ban điều hành đã can thiệp dưới bất kỳ hình thức nào. Khả năng Jarred tự làm điều anh ấy muốn có vẻ hợp lý hơn nhiều, và bản thân anh ấy cũng luôn nói như vậy

  • Tôi không hiểu vì sao trong một cuộc tranh luận về việc chuyển ngôn ngữ lại lôi cả kỳ vọng về giờ làm việc vào. Dù anh ta có là một quản lý tồi đi nữa thì cũng giống như đang cố moi cho ra chất liệu tiêu cực
    Việc phía Zig hầu như không tập trung vào các ưu điểm kỹ thuật của chính việc viết lại cũng rất đáng chú ý. Anthropic đã nêu ra nhiều cải tiến, nhưng gần như không tìm thấy nổi một nỗ lực phản biện nào
    Nếu dự án của tôi được viết lại bằng mô hình ngôn ngữ lớn và kết quả cho thấy mọi thứ tốt hơn mà không có nhược điểm, tôi sẽ rất lo ngại và phản ứng mạnh; còn ở đây thì người ta lại đi bàn chuyện giờ làm việc

  • Có một xung đột lợi ích rõ ràng giữa một dự án do Anthropic sở hữu và ban lãnh đạo của một cộng đồng ngôn ngữ công khai thù địch với mã do AI tạo ra
    Andrew Kelley đáng ra chỉ nên nêu điểm này rồi dừng lại, còn những đánh giá về năng lượng và động cơ của nhà sáng lập Bun thì hầu như không có giá trị bổ sung

    • Rất khó để hai phe tuyệt đối ủng hộ hoặc phản đối AI đi đến thỏa hiệp. Phần lớn các lập luận kỹ thuật lẫn công kích đều là hợp lý hóa sau đó; chỉ là mỗi tổ chức có bối cảnh và mục tiêu khác nhau mà thôi
      Kelley có lẽ cũng biết điều đó, nhưng dường như đã không cưỡng lại được cám dỗ làm mờ trọng tâm. Bài viết gay gắt ([0]: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...) là quá đà, nhưng phần phụ lục kêu gọi cùng tiến về phía trước thì lành mạnh. Tôi cho rằng một BDFL nên hơi cay một chút còn hơn là quá nhạt nhòa.