Suy nghĩ của tôi về việc Bun viết lại bằng Rust
(andrewkelley.me)- Nhà sáng lập Zig Andrew Kelley diễn giải việc Bun viết lại bằng Rust không phải là chuyện thắng thua của tính năng ngôn ngữ, mà là một sự kiện phơi bày sự đổ vỡ quan hệ giữa Zig Software Foundation (ZSF) và Bun/Oven
- Bun thời kỳ đầu thừa nhận Zig là nền tảng cho các thành quả hiệu năng và đã quyên góp cho ZSF khoảng $60.000 mỗi năm, nhưng sau khi trở thành startup được VC hậu thuẫn, các bất mãn xoay quanh cách vận hành tổ chức và chất lượng mã ngày càng lớn
- ZSF lo ngại về các cách triển khai mang tính chắp vá, lạm dụng assertion trong codebase Bun, cũng như việc dành quá ít thời gian để xử lý lỗi và nợ kỹ thuật so với tốc độ bổ sung tính năng; họ cũng thấy áp lực khi Bun bị nhìn như một ví dụ tiêu biểu của Zig
- Kelley chỉ trích bài viết về việc Bun chuyển sang Rust vì dựng vấn đề giảm lỗi thành thế đối lập style guide vs tính năng ngôn ngữ, trong khi theo ông cốt lõi thực sự là thời gian kỹ thuật được đầu tư vào việc loại bỏ lỗi và quản lý chất lượng mã
- ZSF cảm ơn các khoản đóng góp từ Bun, nhưng sau thương vụ Anthropic mua lại thì cả đóng góp lẫn mối quan hệ đều chấm dứt; họ đón nhận tích cực việc viết lại bằng Rust vì điều đó tách biệt lợi ích kinh doanh giữa Zig và Bun
Mối quan hệ ban đầu giữa Bun và Zig
- Jarred tham gia cộng đồng Zig khoảng 5 năm trước, và Kelley nhìn nhận anh là người có “năng lượng người mới bắt đầu” rất mạnh, luôn thử nhanh và học nhiều
- Khi Bun bắt đầu được chú ý như một toolchain JavaScript, Zig cũng bắt đầu thu hút thêm nhiều sự quan tâm
- Kelley cho rằng chỉ với crowdfunding thôi, Jarred cũng có thể tạo ra mức thu nhập ổn định theo mặt bằng San Francisco, nhưng anh đã chọn venture capital do tiếp nhận tư duy kiểu Thiel Fellowship và cách tiếp cận kiểu Silicon Valley
- Bun thời kỳ đầu có thái độ thân thiện với dự án Zig
- Trên website Bun, Zig được ghi nhận cho các thành quả về hiệu năng
- Thiết lập khoản quyên góp hàng tháng tương đương $60.000 mỗi năm cho Zig Software Foundation
- Kelley đánh giá rằng ngay cả trong bài viết về việc Bun viết lại bằng Rust, lời cảm ơn dành cho dự án Zig cũng có vẻ chân thành
Rạn nứt sau khi trở thành startup được VC hậu thuẫn
- Sau khi Bun trở thành startup được VC hậu thuẫn, Jarred dần chuyển từ một lập trình viên phát triển open source cùng cộng đồng sang vị trí gần với người điều hành doanh nghiệp hơn
- Thông điệp tuyển dụng của Oven báo trước cường độ làm việc cao trong khoảng 9 tháng đầu, và nói rõ rằng nếu work-life balance với bạn có nghĩa là “có nhiều thời gian không làm việc” thì nơi này có thể không phù hợp
- Kelley nói rằng khi trò chuyện với ứng viên phỏng vấn và nhân viên của Oven, ông liên tục nghe thấy các nhận xét tiêu cực về vai trò quản lý của Jarred
- Những vấn đề thường được nhắc đến là thiếu giao tiếp, kỳ vọng phi thực tế, ít đồng cảm và thiếu kinh nghiệm
- Kết quả là những thành viên cộng đồng vốn muốn làm việc với Zig lại bắt đầu tránh Oven và Bun
- Càng tập trung vào năng suất và chiến lược exit của startup, Jarred càng đi xa khỏi tầm nhìn dài hạn của Kelley dành cho Zig
- Ví dụ, Jarred từng yêu cầu ưu tiên triển khai Language Server Protocol và tích hợp VSCode, nhưng Kelley có một kế hoạch lớn hơn
Vấn đề chất lượng mã của Bun qua góc nhìn ZSF
- Theo Kelley, vấn đề cốt lõi là chất lượng mã
- Đội ngũ Zig đọc mã nguồn của các dự án người dùng, kiểm tra thay đổi ngôn ngữ ảnh hưởng ra sao tới họ, và test sự cố hỏng hóc cũng như hồi quy hiệu năng do các thay đổi gây ra
- Trong codebase Bun, các thực hành lập trình khiến ZSF lo ngại ngày càng nhiều
- Các cách triển khai mang tính chắp vá cứ tiếp tục chồng chất
- Có lạm dụng assertion
- So với tốc độ thêm tính năng, thời gian dành cho suy xét lại, loại bỏ lỗi và xử lý nợ kỹ thuật là quá ít
- Kelley lo rằng cách làm này của Bun có thể kết hợp với những chỉ trích về memory safety của Zig, nên ông muốn tạo khoảng cách xã hội với dự án Zig
- ZSF đã cố gắng dẫn Bun tới các thực hành lập trình tốt hơn nhưng không đạt hiệu quả
Thương vụ Anthropic mua lại và việc viết lại bằng Rust
- Bên trong ZSF dần hình thành nhận định rằng Bun gần như là một gánh nặng ròng (net liability)
- Việc Bun trông như một ví dụ tiêu biểu của Zig là điều gây áp lực, trong khi trên thực tế nó gần hơn với một ví dụ kiểu “không nên viết code Zig như thế này”
- Kelley cho biết ngay từ đầu ông đã thấy mơ hồ với kế hoạch kinh doanh “bán một thứ gì đó trên cloud” của Bun, và cho rằng nếu một ngày nào đó công ty bị bán đi, Zig cũng có thể bị ảnh hưởng PR tiêu cực một cách gián tiếp
- Sau thương vụ Anthropic mua lại, ZSF cảm thấy nhẹ nhõm
- Khoản đóng góp lặng lẽ dừng lại, và ZSF vốn đã dự đoán điều đó
- Phía Bun không hủy họp hàng tháng nhưng cũng không tham dự, và mối quan hệ được xem như đã chấm dứt
- ZSF nghi ngờ chỉ trong vài ngày nữa sẽ có thông báo viết lại bằng Rust, và họ ủng hộ điều đó
- Sau thương vụ Anthropic, chỉ riêng mối liên hệ gián tiếp rằng Claude được xây bằng Bun, còn Bun được viết bằng Zig, cũng đã trở thành gánh nặng với cộng đồng Zig
- drive-by slop contributions gia tăng
- Những người quá nhiệt tình với AI bắt đầu đổ vào diễn đàn, dán đầu ra của LLM vào các bài đăng
- Kelley lo rằng Zig sẽ bị biết đến như một ngôn ngữ lập trình gắn với AI
- Khi Jarred công bố việc viết lại bằng Rust, Kelley rất hoan nghênh và bày tỏ cảm giác rằng giờ đây chuyện đó “không còn là vấn đề của tôi nữa”
Phản bác bài viết của Bun về việc viết lại bằng Rust
- Kelley cho rằng bài viết của Bun về việc viết lại bằng Rust được viết tốt, nhưng vẫn chỉ ra một vài vấn đề cốt lõi
-
Cốt lõi của việc giảm lỗi
- Bài viết của Bun dựng vấn đề như thể để tránh lỗi, bạn phải chọn giữa style guide và tính năng của ngôn ngữ lập trình
- Với Kelley, cách chính để loại bỏ lỗi là đầu tư nguồn lực kỹ thuật để tìm và sửa lỗi
- Ông cho rằng TigerBeetle đã dành thời gian để tìm và loại bỏ lỗi, đồng thời duy trì quan hệ lành mạnh với ZSF, còn Bun thì không làm được cả hai
-
Mâu thuẫn quanh test suite
- Theo Kelley, bài viết của Bun lấy việc test suite là đủ làm lý do để có thể phát hành 1 triệu dòng code chưa được review
- Nếu vậy, ông đặt câu hỏi vì sao code Zig lại có nhiều lỗi khó chịu, và vì sao test suite không bắt được lỗi trong code Zig nhưng lại có thể bắt lỗi trong 1 triệu dòng code chưa được review
-
Hiệu năng và LTO
- Bài viết của Bun quy phần cải thiện hiệu năng cho LTO, nhưng Kelley nói Zig đã hỗ trợ LTO trong toàn bộ giai đoạn Bun tồn tại
- Trước đây Zig từng bật LTO mặc định, nhưng sau đó loại khỏi cấu hình mặc định vì có quá nhiều lỗi trong LLVM; những lỗi này cũng ảnh hưởng tới Rust
- Kelley cho rằng rất có thể ZSF đã khuyến nghị bật LTO nhưng Bun đã không lắng nghe
-
fuzzing
- Bài viết của Bun hàm ý như thể họ đã fuzzing một cách nghiêm túc với code Zig, nhưng Kelley nói rằng trong một cuộc gọi, đội ngũ Bun từng bảo với ông rằng họ không fuzzing bất cứ thứ gì
-
Kích thước binary và
comptime- Bài viết của Bun đưa ra nhiều công việc kỹ thuật nhằm giảm kích thước binary như một cơ sở để biện minh cho việc viết lại bằng Rust, nhưng Kelley cho rằng những việc đó không liên quan đến bản thân việc viết lại
- Những việc này gần hơn với loại công việc kỹ thuật lẽ ra phải được thực hiện ngay từ đầu trên codebase Zig
- ZSF đã cảnh báo suốt nhiều năm về việc Bun lạm dụng
comptime, và còn tạo tính năng time report để có thể kiểm tra mức độ sử dụngcomptime/inlinecũng như thời gian biên dịch
-
Tốc độ biên dịch
- Kelley chỉ ra rằng bài viết của Bun không hề nhắc tới tốc độ biên dịch
- Dự án compiler Zig có khoảng 600.000 dòng code, quy mô tương tự Bun trước khi viết lại
- Theo số đo của Kelley, việc build từ đầu với cache sạch mất 16 giây, còn sau khi bật incremental compilation thì mỗi lần chỉnh sửa tiếp theo mất 90ms
- Ông đặt câu hỏi rằng sau khi viết lại bằng Rust, các con số đo tương ứng của Bun là bao nhiêu
Kết luận của Kelley
- Với Kelley, vấn đề cốt lõi không phải là tính năng ngôn ngữ lập trình mà là sự đổ vỡ quan hệ
- ZSF chân thành cảm ơn các khoản đóng góp nhận được từ Bun, và đã dùng số tiền đó cho thù lao cộng tác viên Zig
- Kelley nói rõ rằng ông không có ý chỉ trích Jarred một cách ác ý
- Jarred có gu, mục tiêu sống khác ông, nhưng theo ông thì Jarred đã thành công trong việc tạo ra cuộc sống mà mình mong muốn
- Ông chấp nhận rằng Jarred đang hạnh phúc và thành công, và nói rằng mình không mang ác ý
- Tuy vậy, Kelley vui vì lợi ích kinh doanh giữa ZSF và Bun không còn đan xen nữa
- Ông cho rằng khi cuộc tranh luận công khai về việc viết lại bằng Rust là tốt hay xấu với tư cách tiêu chí chọn ngôn ngữ kết thúc, thì các tương tác giữa hai bên cũng sẽ chấm dứt
2 bình luận
Đọc bài này xong khiến mình chẳng còn muốn dùng cả zig lẫn bun nữa.
Các ý kiến trên Hacker News
Tôi đã học được rất nhiều khi đọc mã của Andrew, và như bài gốc đã nói, nếu không có Zig thì cũng đã không có Bun
Về đoạn “Bài viết tuyên bố rằng họ đã fuzz mã Zig, nhưng trong cuộc gọi, toàn bộ đội ngũ Bun nói rằng họ không fuzz bất cứ thứ gì. Điều này trông như một sự bịa đặt trắng trợn”, có PR tích hợp Fuzzilli: https://github.com/oven-sh/bun/pull/24826
Cũng có các PR đã merge để sửa những vấn đề mà Fuzzilli tìm thấy trong mã Zig của Bun: https://github.com/oven-sh/bun/pull/28926, https://github.com/oven-sh/bun/pull/28934, https://github.com/oven-sh/bun/pull/29255, https://github.com/oven-sh/bun/pull/29210, https://github.com/oven-sh/bun/pull/29199
Tìm “Fuzzilli” sẽ ra thêm nhiều PR: https://github.com/search?q=repo%3Aoven-sh%2Fbun+is%3Apr+Fuz...
zig build test --fuzz, tức fuzzer tích hợp sẵn của Zig, và công cụ nằm trong phạm vi của ông ấy là thứ đóTôi không tôn sùng ai trong hai người cả, chỉ tò mò vì toàn bộ cuộc đối thoại dường như đang xấu đi thay vì đi theo hướng tốt hơn
Việc bị downvote chỉ vì đặt câu hỏi kiểm chứng sự thật khá là đáng chú ý. Cũng có thể câu trả lời đơn giản là “cho đến gần đây họ chưa dùng fuzzer nên cả hai đều đúng”, nhưng tôi không biết nên mới hỏi
Bài viết này là một việc thiếu chuyên nghiệp và đáng xấu hổ cho Zig
Tôi gần như không biết gì về Jarred, nhưng bài của anh ấy mà tôi đọc hôm qua có giọng điệu biết ơn Zig, và giờ nhìn lại thì anh ấy cũng đã quyên góp một khoản tiền đáng kể cho Zig
Toàn bộ bài này đang công khai và mang tính cá nhân tấn công anh ấy chỉ vì đã chọn một sản phẩm khác
Nếu Andrew nghĩ bài này sẽ biện hộ cho Zig thì thật kỳ lạ, thực tế nó chỉ khiến Zig trông trẻ con. Hoặc có lẽ ông ấy chỉ muốn tấn công Jarred
Có phải ai cũng phải trở thành một thương hiệu biết đi, lúc nào cũng phải lọc lời, đi trên băng mỏng, và núp sau ngôn ngữ kiểu công ty để trông “chuyên nghiệp” không?
Thế giới hiện nay cần nhiều diễn ngôn thẳng thắn hơn chứ không phải ít đi, và các tương tác trực tuyến dường như ngày càng kém chân thật
Zig trên thực tế gần như là dự án một người, và người đó đang đưa ra những quyết định ngày càng bất ổn
Tất nhiên đó là dự án của ông ấy nên ông ấy có quyền, nhưng nếu là một công ty gần như có giá trị hàng nghìn tỷ, họ sẽ không muốn gánh loại rủi ro chuỗi cung ứng này
Từ góc nhìn của Anthropic, thay vì đầu tư thêm vào hệ sinh thái Zig, tốt hơn là cắt từ trong trứng nước khi rủi ro rằng not-so-BDFL vượt giới hạn đã lộ rõ
Trong khi đó, xét theo quy mô được áp dụng và thời gian phát triển, độ phủ kiểm thử của Zig thấp đến mức đáng xấu hổ
Thái độ của Zig với AI hoàn toàn trẻ con. Dù có thể hưởng lợi lớn, họ cũng không xem xét bất kỳ khả năng ứng dụng nào
Ngăn PR spam là một chuyện, còn tự trói tay trói chân và ngay cả trong nội bộ cũng hoàn toàn không dùng AI ở lĩnh vực dễ nhất và có hiệu quả cao nhất lại là chuyện khác
AI cũng có thể sàng lọc các ứng viên bug thật trong đống PR spam, nhưng vì họ không nhận bất kỳ trợ giúp nào nên các bug thật bị bỏ mặc lâu hơn mức cần thiết
Đáng tiếc là có quá nhiều nhà phát triển mã nguồn mở quá thoải mái khi viết theo kiểu này, và đó là một trong những lý do tôi ngừng hoạt động mã nguồn mở
Ở một nơi làm việc hợp lý, nếu hành xử kiểu này thì sẽ bị sa thải hoặc ít nhất là bị kỷ luật
Câu “không có phê phán cá nhân nào nhằm vào Jarred” là một phát biểu khá mạnh khi đặt ở cuối một bài mà gần như toàn bộ trông giống những lời chỉ trích cá nhân được che đậy rất mỏng
Kiểu như nói ai đó có năng lượng của người mới rồi bọc nó bằng sự tích cực giả tạo như “một người thất bại rồi học hỏi”, hoặc viết rằng theo lời đồn người đó bị gọi là “quản lý bốc mùi”
Nó gần giống “tôi không nói là người này tệ, nhưng tôi phải viết lên blog rằng mọi người đều đồng ý người này tệ”; dù có đúng thì cũng trông rất kém duyên
Tôi cũng làm việc với những quản lý tệ hại, nhưng cá nhân tôi không thù hằn họ
“Mạng lưới tin đồn rất lớn và khỏe mạnh, đầy những chùm nho mọng nước, và nước ép của tất cả những chùm nho đó đều mang cùng một thông điệp: Jarred là một quản lý bốc mùi”
“Jarred đã viết những thứ rác rưởi ngay cả trước khi dùng LLM”
Bài viết trẻ con một cách kỳ lạ. Tôi thích những bài không qua bộ lọc kiểu công ty và nói thật suy nghĩ bên trong, nhưng những bài như vậy cũng cho thấy người đó suy nghĩ và hành xử ra sao
Với năng lực lãnh đạo tốt, dù bỏ bộ lọc kiểu công ty đi thì kết quả vẫn chuyên nghiệp; bài này phơi bày thứ gì đó kém hơn thế rất nhiều
Khi an toàn và không có ai phụ thuộc vào mình thì điều đó hoàn toàn bình thường. Nó khác với công việc quản lý
Đoạn ZSF thở phào nhẹ nhõm sau khi thương vụ Anthropic hoàn tất rất ấn tượng. Nghĩa là họ vẫn để sẵn tài khoản ngay cả khi khoản quyên góp lặng lẽ bị dừng, và cũng không ngạc nhiên khi cuộc họp hằng tháng không bị hủy nhưng người kia cũng không xuất hiện. Mối quan hệ đã kết thúc rồi
Tôi đã thấy chuyện này nhiều lần. Khi một dự án hay tổ chức bị mua lại, “những việc tốt” mà họ đang làm không kết thúc ồn ào, mà chỉ biến mất khi nhà tài trợ bắt đầu lặng lẽ phớt lờ
Thật may là họ đã đọc được dấu hiệu và chuẩn bị. Đây là một bài học hay mà không cần phải tự mình vất vả trải qua, và các dự án tự do/mã nguồn mở phụ thuộc vào một hai nhà tài trợ lớn nên cẩn trọng
Tôi nghĩ sắp tới chúng ta sẽ thấy chuyện này nhiều hơn trong hệ sinh thái công cụ dành cho lập trình viên
Ở các chỗ khác trong thread này có những phản ứng gay gắt về giọng điệu của bài, nhưng bài này đã làm tôi giảm kỳ vọng vào Zig
Drama thì thú vị và sự chân thành của Andrew có lẽ đáng nể, nhưng đây không phải là kiểu chuyên nghiệp cần có cho một dự án nghiêm túc
Dù có vẻ nhàm chán và không truyền cảm hứng, tôi vẫn muốn tech stack và cách vận hành nó có sự ổn định như vậy
Jarred có thể là khoản lỗ ròng, nhưng Bun là một dự án rất lớn dùng Zig, và việc dự án đó rời đi không phải là điều tốt cho Zig như Andrew nói
Anh ấy có vẻ đặt sự thuần khiết và hệ tư tưởng lên ưu tiên cao hơn nhiều so với tăng trưởng của ngôn ngữ. Với một ngôn ngữ lập trình nghiêm túc, mức độ được chấp nhận và quy mô tới hạn cũng là những yếu tố quan trọng
Nó giống như nói Linux không thể là một dự án nghiêm túc vì giọng điệu email của Linus
Thậm chí đây cũng không phải là viết trực tiếp cho họ, mà là một bài trên blog cá nhân
Điều quan trọng chẳng phải là những đóng góp của anh ấy cho ngôn ngữ sao?
Tại sao nhất thiết mức độ được chấp nhận và quy mô tới hạn lại quan trọng? Tại sao không thể tạo ra một ngôn ngữ phù hợp với sự thuần khiết và hệ tư tưởng mình muốn, dù phải từ bỏ việc được chấp nhận rộng hơn?
Tại sao mọi thứ đều phải được tối ưu cho tăng trưởng người dùng và độ nhận diện?
Ngay cả khi họ giả vờ như vậy
Bài này rất mới mẻ. Hẳn sẽ rất dễ bị cám dỗ đáp trả các cách diễn đạt kiểu PR trong bài của Bun một cách tinh vi hơn, nhưng tác giả đã không làm vậy
Anh ấy có thể đưa vào những sự thật khiến Jarred trông tiêu cực nhưng cẩn thận giấu ý kiến của mình, chẳng hạn như “tôi nghe nói người ta gọi anh ta là quản lý bốc mùi. Không phải tôi gọi vậy đâu, người khác gọi vậy”, nhưng tôi thích việc bài viết cứ thẳng thắn
Tuy nhiên, nội dung của tính cách và suy nghĩ đó thì khá khó chấp nhận
Vì phần đầu tiên và lớn nhất của bài được dành cho các công kích cá nhân mang tính suy đoán, tôi khó đặt niềm tin vào lời tác giả
Đây đã có thể là một cơ hội tốt để tổng hợp các điểm mạnh của Zig. Gần đây tôi muốn học Zig nhờ các bài viết truyền cảm hứng và mang tính truyền đạo của mitchellh, nhưng bài này làm tôi nguội hẳn ý định học Zig
Có khá nhiều nội dung về cách Andrew nhìn nhận Jarred cũng như cách làm việc và thái độ công việc của anh ấy, nhưng tôi không thấy rõ đâu là công kích cá nhân, đâu là suy đoán hay không
Các công kích cá nhân nhắm vào Jarred dường như chẳng giúp ích gì nhiều cho lập luận rằng nên dùng Zig
Lẽ ra nên tập trung vào ngôn ngữ, chứ không nên dùng những cách diễn đạt như “người bảo trì bốc mùi”
Thành thật mà nói, đọc bài này khiến tôi muốn tránh Andrew cũng chẳng kém gì Jarred
Đây cũng là điều mà nhiều người trong cộng đồng đã chứng kiến trong vài tháng gần đây
Nói rằng “Jarred, trong vai trò nghề nghiệp của mình, đã khiến nhiều người trong cộng đồng chúng ta rời đi, và chúng ta muốn giữ khoảng cách” không có nghĩa là “Jarred là người xấu trong đời tư”
Tất nhiên trong ngành này, khi nghĩ đến việc các VC còn để lại bao nhiêu đời sống riêng tư ngoài công việc, điều đó có thể bị hiểu gần như cùng một nghĩa, nhưng đó không phải vấn đề của Andrew
Tôi không bênh vực văn phong của Andrew. Khi nói với một nhóm độc giả có kiểu thần kinh điển hình rộng hơn, có lẽ anh ấy đã có thể che bớt phần đa dạng thần kinh của mình
Dù vậy, đó là dự án của anh ấy, cộng đồng của anh ấy vốn đã biết đặc điểm này, và đây cũng là một biến số đã biết
Có thể sẽ hữu ích nếu đọc lại với giả định rằng Andrew hoàn toàn chân thành, thay vì gán thêm hàm ý phụ rằng “Andrew đang cố ám sát nhân cách Jarred”
Đây cũng không phải lần đầu tôi thấy một bài viết mà tôi cảm nhận là ác ý một cách lộ liễu. Nó không chỉ ở mức có thể nói giảm nói tránh là “thẳng thắn”
“Im lặng chẳng phải cũng là một lựa chọn sao?”
Trái với câu “không có phê phán cá nhân nào nhắm vào Jarred”, toàn bộ bài viết có cảm giác như phê phán cá nhân nhắm vào Jarred
Ngay cả nếu đó là sự thật, công khai theo hình thức này cũng không khôn ngoan. Nếu mục tiêu là bảo vệ Zig, hoàn toàn có thể làm theo cách ít mang tính cá nhân hơn
Toàn bộ việc viết lại Bun từ Zig sang Rust này trông giống một nước đi marketing lớn
Nếu Anthropic AI thật sự mạnh đến vậy, tại sao không giao cho nó một nhiệm vụ tham vọng hơn: sửa lỗi và thiết kế lại codebase Bun Zig hiện có để không chỉ xử lý các lỗi hiện tại mà còn ngăn những lỗi tương tự xuất hiện trong tương lai?
Điều đó đã làm Anthropic phật ý
Có thể tưởng tượng rằng Anthropic vốn đã muốn mua lại Bun ngay cả khi không có màn dàn dựng này
Vài tuần sau, Bun bắt đầu viết lại bằng Rust. Dù không được nói rõ, tôi nghĩ hai sự kiện này có thể có liên quan
Tôi không biết bên nào tệ hơn