- Vấn đề này hiện ở trạng thái Open, cuộc thảo luận đã bị khóa vì lệch chủ đề và bị giới hạn cho collaborator, đồng thời có liên kết với các bản sửa liên quan #30728 và #30876
- Người báo cáo cho biết giá trị được tạo bằng
PathString::init vẫn có thể gọi slice() sau khi Box gốc đã bị drop, và Miri báo Undefined Behavior dựa trên dangling reference
- Mã tái hiện có dạng truyền buffer được tạo bằng
Box::new(*b"Hello World") vào PathString::init(&*test), rồi gọi init.slice() sau drop(test); Miri phát sinh lỗi tại core::slice::from_raw_parts
- robobun xác nhận có thể tái hiện vấn đề, và tóm tắt rằng
PathString::init là hàm safe nhưng lại xóa slice lifetime, khiến có thể tạo &[u8] bị dangling
- #30728 liên quan chuyển các lỗ hổng song song trong
PathString::init và dir_iterator::next() thành unsafe fn, đồng thời thêm chú thích SAFETY nêu rõ backing allocation tại khoảng 70 vị trí gọi
- Cùng bản sửa đó cũng được mô tả là bao gồm compile_fail doctest để bắt buộc từ khóa
unsafe trong ba signature, cùng với bản sửa fd leak của lỗi readdir trong resolver
- AwesomeQubic nói thêm rằng
PathString::init còn xóa provenance và cũng thất bại dưới MIRIFLAGS=-Zmiri-strict-provenance
- JavaDerg giải thích rằng
init nhận lifetime ngầm của &[u8], rồi xóa nó bằng thao tác unsafe và trả về Self trông như 'static, từ đó cho phép use-after-free và invalid aliasing
- JavaDerg cảnh báo rằng trên mô hình an toàn của Rust, UB có thể gây ra vấn đề ở những vị trí khó lường, nên cần rà soát rộng việc dùng
unsafe, và không phù hợp khi dịch nguyên xi 1:1 cách quản lý bộ nhớ của ngôn ngữ khác sang Rust
- robobun đã thêm các commit liên quan gồm
PathString::init signature stays unsafe để kiểm thử và dir_iterator: make next() unsafe; audit call sites
- SimonReiff cho biết kết quả grep
unsafe trong các tệp Rust của kho, không tính chú thích, là 13255 dòng, và yêu cầu hoàn tác ngay cũng như thảo luận chính sách và quy trình dùng mã AI
- Jarred-Sumner cho biết bản port Rust hiện lấy 1:1 mapping gần với mã Zig gốc nhất có thể làm điểm xuất phát và đang được cải thiện, đồng thời đề nghị tiếp tục báo các lỗi hoặc hành vi unsound trong mã Rust bằng issue mới
1 bình luận
Ý kiến trên Hacker News
Lúc đầu tôi quan tâm đến Bun vì nó được viết bằng Zig, và tôi bị Zig thu hút vì tôi tin vào các quyết định và gu của Andrew Kelley
Những lý do khiến tôi hứng thú hơn với Bun về sau rốt cuộc cũng vì đó là những lựa chọn mà tôi thấy đáng tôn trọng, nên ngay cả sau thương vụ Anthropic mua lại, tôi vẫn cố giữ sự lạc quan một cách thận trọng
Nhưng bước đi lần này trông như một quyết định khó mà tin tưởng; không phải Rust tự nó có vấn đề, mà nếu Anthropic quản lý Bun theo kiểu này thì tôi thấy khó tiếp tục đặt cược vào nó như một thành phần đáng tin trong bộ công cụ của mình
Không chỉ cần tin vào mã nguồn mà còn phải tin vào cách tư duy đằng sau nó, và lúc này nó trông giống một công cụ chỉ dành cho nội bộ Anthropic
Hướng đi lần này có thể là một cách để sửa điều đó, nên cứ chờ xem
Là một fan Deno lâu năm, Bun trông giống một Deno ít tham vọng hơn, và vì tôi không muốn học Zig nên khả năng tôi động vào chính Bun, dù chỉ như một sở thích, cũng rất thấp
Nhưng vài năm gần đây, khi phải duy trì một codebase TypeScript khá lớn theo cách ít phụ thuộc runtime hơn, tôi dần cởi mở hơn với Bun; tôi không muốn biến việc dùng một TypeScript runtime cụ thể thành yêu cầu bắt buộc, nhưng Bun liên tục đưa ra các lý do như Deno đã làm: Postgres, SQLite, S3, websocket, kho bí mật cục bộ, bundling, compile, tốc độ cao
Giờ tôi đang biến nhiều API server và frontend app server thành một tệp thực thi duy nhất bằng
bun build --compile --bytecodeđể chạy và triển khai gần như ở mọi nơiDù vậy, tôi không nghĩ cách này là phổ biến, và nếu đợt port dựa trên LLM này thất bại thì tôi đang ở đúng vị trí để phải hối hận về toàn bộ các quyết định liên quan đến Bun
Nhưng nếu nó không thất bại thì sẽ rất thú vị. Nó sẽ là một ví dụ cho thấy có thể làm được gì với LLM, và việc Bun được phát triển bằng Rust về sau theo tiêu chí của tôi lại là một điểm cộng
Ngược lại, nếu thất bại thì nó cũng rất quan trọng về mặt thông tin. Bun là một trong những runtime TS/JS lớn, còn Anthropic có nguồn lực khổng lồ, quyền truy cập các model mới nhất và về cơ bản là ngân sách vô hạn, nên nếu họ cũng không làm được thì điều đó gần như có nghĩa là hiện giờ chuyện này thực sự vẫn là bất khả thi
Nếu đã định chuyển Zig sang Rust không an toàn thì tôi không hiểu vì sao họ không làm một công cụ dịch
Chỉ cần ánh xạ cấu trúc ngôn ngữ một-một và hardcode các pattern của codebase là đã có thể có được phép chuyển đổi mang tính quyết định; như một người bạn tôi nói, kiểu “nối
zig translate-cvàoc2rust” cũng đã có thể làm đượcKết quả hiện tại còn kém đáng tin hơn cả đầu vào. Đầu vào thì không an toàn bộ nhớ nhưng là mã do con người trực tiếp viết; đầu ra thì vừa không an toàn bộ nhớ, vừa là vibe coding, lại có vẻ chưa từng được con người xem xét tử tế
Tôi không hiểu việc lạm dụng AI kiểu agent cho mục đích này có ý nghĩa gì
Nó bắt chước ngữ nghĩa con trỏ không an toàn của C bằng một thư viện hàm không an toàn trong Rust, nên kết quả trông rất kinh khủng
Vài năm trước khi xem một bug của OpenJPEG, có người thử chuyển bằng c2rust, và phần Rust không an toàn sau chuyển đổi cũng gặp segmentation fault ở đúng chỗ như mã C
Tương thích thì có, nhưng không an toàn
Ý chính là đừng thao tác chuỗi bằng C hoặc Rust không an toàn. Đó hoàn toàn không phải công cụ phù hợp cho công việc này
zig translate-cvàoc2rust” không hoạt động như bạn nghĩNhững công cụ kiểu này nhiều lỗi và làm mã trở nên cực kỳ dài dòng, khó suy luận
Nó có thể dùng được với ứng dụng nhỏ, nhưng không phù hợp cho một cuộc tái viết toàn bộ
Thay vì dịch Zig sang Rust, tôi nghĩ tốt hơn là viết một trình phân tích JPEG bằng Python tĩnh, rồi hạ nó xuống Zig và Rust với cấu trúc thành ngữ phù hợp cho từng ngôn ngữ
Vì mục tiêu đó, tôi đã làm một parser cho một phương ngữ Python dành riêng cho mục đích này, và định chấp nhận một số tính năng của Rust/Zig giúp việc dịch dễ hơn mà vẫn giữ tương thích với phần lớn mã Python
Trình phân tích JPEG cũng có trong các tài nguyên ví dụ
https://github.com/py2many/static-python-skill
https://github.com/py2many/spy-ast
Issue này dễ gây hiểu lầm
Vấn đề không phải là sự tồn tại của undefined behavior mà miri có thể bắt được, mà là việc nó đã lộ ra API có thể gây undefined behavior trong mã an toàn. Ngay cả miri cũng chỉ bắt được khi có test chứng minh điều đó
Khi đang port ban đầu từ một ngôn ngữ không an toàn thì chuyện này không hoàn toàn là phi lý
Có vẻ đội Bun cũng đang dần kiểm tra xem các hàm bọc quanh mã không an toàn sau đó có đúng hay không
Trong giai đoạn port, việc tạm thời đánh dấu nhầm một số hàm không an toàn là an toàn tự nó không phải vấn đề quá lớn, nhưng merge chúng vào kho chính ở trạng thái đó thì hơi lạ
Vấn đề thực sự là khi phát hành mã ở trạng thái này
Điều đáng tiếc là họ đã không cấu hình để chạy test bằng miri ngay lập tức. Vì LLM phản ứng rất tốt với test tốt
Tôi nói vậy không phải vì issue GitHub này, mà vì một test khác [1] thực sự gọi đến undefined behavior mà miri sẽ bắt được; tuy nhiên có vẻ đoạn mã đang được test đó chẳng được dùng ở đâu nên tác động thực tế có lẽ không lớn
Đây mới là giai đoạn đầu của việc port, nên sau này có thể sửa, và thực ra còn có thể loại bỏ phần mã không an toàn vốn không cần thiết
[1] https://github.com/oven-sh/bun/blob/4d443e54022ceeadc79adf54... - các con trỏ được suy ra từ tham chiếu mutable đầu tiên bị làm mất hiệu lực khi các tham chiếu mutable mới tới cùng đối tượng được tạo ra. Theo kiểu C thì có thể nghĩ “tham chiếu mutable” là “tham chiếu
restrictnơi có thực hiện sửa đổi không tầm thường”Cách làm đúng là suy ra mọi con trỏ từ cùng một tham chiếu mutable, nhưng họ đã không làm vậy
Nếu mọi người kéo nhau sang GitHub spam thì chỉ càng làm giảm khả năng họ tiếp tục làm việc công khai. Tôi hy vọng đừng như vậy
Và tốt hơn là nên tạm hoãn phán xét cho tới khi nó đạt trạng thái có thể công bố được. Đánh giá một phần việc đang dang dở vừa không công bằng vừa chẳng mấy thú vị
mainluôn hoạt độngVì CI/CD về cơ bản dựa trên giả định rằng mọi commit đều phải chạy được
Mã đang dở dang, chưa chạy được như một cuộc tái viết toàn bộ, nên nằm ở nhánh riêng
Như vậy khi cần làm việc như vá bảo mật thì vẫn có thể giữ
mainhoạt độngKết quả như vậy không có gì lạ vì thứ được yêu cầu gần như là một bản port dịch sát
Có thể lập luận rằng tốt hơn là trước hết chuyển Bun sang một ngôn ngữ có hệ thống kiểu mạnh hơn, rồi dùng chính hệ thống kiểu đó làm bàn đạp cho các cải tiến tiếp theo
Có vẻ vẫn hơn là đòi hỏi sự hoàn hảo ngay từ bước đầu
Họ đang xử lý các issue phát sinh
Nhưng việc API của mã Rust có thể gây undefined behavior dù không được đánh dấu
unsafethì thật đáng thất vọngNếu làm kiểu dịch này, tôi sẽ đi theo hướng bảo thủ và ban đầu đánh dấu toàn bộ hoặc phần lớn là
unsafeSau đó mới từng bước xác minh độ an toàn của từng mảnh riêng lẻ
Thành thật mà nói, tôi hơi ngạc nhiên khi họ nói đã làm cho nó hoạt động hoàn toàn chỉ trong một tuần
Side project của tôi là https://tsz.dev cũng có tham vọng tương tự, nhưng tôi không thể nói là đã thành công
Tôi vẫn đang tiếp tục thêm test để xác nhận hành vi, và ngay cả sau khi vượt qua toàn bộ test của chính TypeScript, tôi vẫn tìm ra bug đúng như dự đoán
Tiêu chuẩn khớp với hành vi của
tscthực sự là cực kỳ caohttps://github.com/type-challenges/type-challenges
Tôi không phản đối việc dùng LLM để viết nhiều mã, nhưng giờ khi đã có thể đẩy ra mã với tốc độ này thì khâu xác minh phải vững gấp 100 lần
Tôi không phản đối việc dùng agent, nhưng làm gấp kiểu này rồi bất ngờ quăng vào cộng đồng thì trông cực kỳ nghiệp dư
Đây là kiểu hành động mà người ta mong ở một kỹ sư mới vào nghề đầy nhiệt huyết
Cái này rất tuyệt. TypeScript cần nhiều thứ như vậy hơn, và tôi hy vọng nó được biết đến rộng hơn để Microsoft có thể áp dụng
Tuy vậy, có lẽ nên cẩn thận khi gọi nó là sound mode
Trong câu “đây không phải là bằng chứng về tính soundness theo nghĩa toán học, và nó không làm cho các file
.d.tsbên thứ ba trở thành chân lý” đang trộn lẫn hai ý hoàn toàn khác nhauThứ nhất, soundness là một khái niệm toán học. Nếu cái gì sound thì nó thực sự sound, tức là có thể tin compiler mà không cần tự tay kiểm tra từng chi tiết
Nếu có bug trong triển khai thì nó có thể hoạt động sai, nhưng bug đó có thể sửa; còn soundness nghĩa là trong đặc tả hoặc chính hệ thống kiểu về mặt lý thuyết không có bug kiểu “có thể sai” như vậy
Thứ hai, việc một ngôn ngữ thực tế cần các tính năng không được kiểm tra mà người ta tin rằng sẽ được dùng đúng là chuyện hoàn toàn ổn và có thể dự đoán trước. Ví dụ như
unsafeCoercecủa Haskell haysun.misc.unsafecủa JavaVấn đề thật sự là khi hệ thống kiểu bị phá vỡ dù bạn không hề dùng tới những tính năng đó
Tôi chỉ nhìn mã vài phút thôi nhưng có cảm giác bật tối ưu hóa lên là nó sẽ vỡ rất nặng
Với một test suite lớn sẵn có, thêm công cụ để chạy song song các agent và gần như ngân sách token vô hạn thì cũng không cần quá nản lòng
Có một cuốn sách đã thay đổi khá nhiều cách tôi nhìn về sự chú ý và truyền thông [0]
Bản thân cuốn sách không hẳn là quá xuất sắc, nhưng có nêu ra một điểm liên quan ở đây
Có một sự bất đối xứng rất lớn giữa độ lan tỏa của những tuyên bố lớn, hào nhoáng, ví dụ như “Bun đã được tái viết thành Rust an toàn bộ nhớ chỉ trong vài tuần”, và độ lan tỏa của những lời đính chính, ví dụ như các chú thích trong bài cũ hay các issue GitHub
Ngành marketing và PR hiểu rất rõ và tích cực khai thác sự bất đối xứng này
[0] https://en.wikipedia.org/wiki/Trust_Me,_I%27m_Lying
Tính đến lúc này, phần lớn trông khá nông
Việc merge một bản port lớn có hỗ trợ LLM rõ ràng là một quyết định rất táo bạo, nhưng trong những gì mọi người đang chỉ ra về sản phẩm thực tế, tôi không thấy nhiều thứ tệ hơn các bản port đang làm dở khác
Mỗi issue được phát hiện đều đang bị thổi phồng quá mức
Trong mọi cuộc thảo luận về chủ đề này đều có hàng chục bình luận nói kiểu codebase vibe coding này sắp nổ tung vì các khối
unsafechưa được audit, lại được review qua loa bởi những người có vẻ không hiểu RustThậm chí đôi khi còn có cảm giác họ đang giận dữ với chính ý tưởng rằng đã là ngôn ngữ lập trình thì phải hiểu nó
Người ta thường nhớ bài gốc hoặc tiêu đề, nhưng lại không thấy phần đính chính
Việc port vẫn đang tiếp diễn nên chưa có một tuyên bố lớn hào nhoáng nào cả, và nó cũng chưa hoàn tất hay phát hành
Thứ tuyên bố hào nhoáng mà tôi thấy lại là những màn chế giễu kiểu đánh nhanh rút gọn nhằm vào mã đang làm dở, kèm theo các nỗ lực ám chỉ như thể đội ngũ đã nói rằng nó hoàn thành hoặc hoàn hảo rồi
Bản tái viết đơn thuần là một bản dịch mã để lấy đó làm điểm khởi đầu
Đội Bun chưa từng tuyên bố rầm rộ rằng mã giờ đã an toàn bộ nhớ, mà luôn nói rõ đó chỉ là điểm xuất phát
Tức là việc kỳ vọng nó phải lập tức hoàn hảo và giải quyết mọi vấn đề bộ nhớ của mã Zig gốc là đang tranh luận với một tuyên bố tưởng tượng chứ không phải tuyên bố thực tế của đội Bun
Tôi cũng tò mò không biết đã có ai thử đối chiếu xem những vấn đề bộ nhớ này có tồn tại trong codebase gốc hay không
Những loại lỗi này là điều có thể lường trước
Với những người cần sự ổn định thì bản ổn định vẫn là Zig, và cuối cùng các lỗi này rồi cũng sẽ được sửa
Hệ sinh thái Rust có những công cụ rất quen thuộc để bắt các lỗi như vậy, và dù không thể bắt hết mọi undefined behavior phát sinh từ lỗi trong các khối
unsafe, việc chạy chúng vẫn được xem là thực hành tốtĐiều khiến tôi lo nhất là siêu đối thoại
Ban đầu tôi nhìn các maintainer đã đóng issue GitHub này vì cho là lạc đề với con mắt khá chỉ trích
Nhưng rồi UI GitHub đang tự động gộp và thu gọn một loạt tin nhắn hoàn toàn không có giá trị thông tin, và những tin nhắn đó trông như kéo đến từ diễn đàn hoặc Discord cộng đồng
Điều này đẩy tất cả vào tình huống cùng thua
Một người phát hiện ra vấn đề nghiêm trọng mà nhiều cộng đồng liên quan có lý do để lo ngại thì hoàn toàn có đủ lý do để thông báo rộng nhất có thể
Đây là một yêu cầu thực chất liên quan đến thay đổi gần đây, và việc soi giọng điệu không làm mất đi tính xác thực của nó
Vấn đề là sự chú ý bổ sung lại đang giết chết cuộc thảo luận theo nghĩa đen
Nó cũng có thể trở thành lá chắn cho bên maintainer, nhất là cho những người đưa ra quyết định cảm tính hơn hoặc gần với cơn loạn AI
Một dự án có tâm lý bị bao vây đến mức chặn và phớt lờ mọi chỉ trích rất dễ trượt bánh cực nhanh
Ngược lại, ở những dự án không bảo vệ maintainer khỏi nỗi lo và sự bệnh lý xoay quanh AI thì việc maintainer kiệt sức là điều không thể tránh
Đợt tái viết Bun lần này tạo cảm giác như một sự kiện tiềm năng phục vụ marketing kiểu Mythos
Tính đến lúc này, phần lớn sự bàn tán và quảng bá lại đến từ phản ứng tiêu cực của những người phản đối AI
Theo tôi, chuyện này cũng đan xen khá nhiều với hình ảnh tiêu cực ngày càng tăng về chính Anthropic do một số quyết định gần đây của họ
Cảm giác như nhu cầu của Anthropic là ưu tiên duy nhất, còn mọi thứ khác thì không quan tâm
Rồi hô hào thật lớn và viết blog kiểu “Claude Code đã giúp đội Bun tái viết hơn 1 triệu dòng Zig sang Rust” để các VC chảy nước miếng
Nó trượt cả những kiểm tra cơ bản
Không biết còn đốt bao nhiêu tiền nữa để Mythos xé nát codebase ra từng mảnh
Viết thêm một bài blog khác
Những kẻ lừa đảo và những người ngây thơ vỗ tay, bênh vực nó để chống lại “đám phản AI hoang tưởng”
Các VC lại càng kích động hơn
Đây là cách kiếm tiền
Và rồi câu chuyện sẽ trôi sang kiểu bây giờ phải loại bỏ luôn cả kỹ sư phần mềm
Tôi không hiểu vì sao lại giả định rằng một codebase của ngôn ngữ không an toàn, còn có thêm cả binding sang một ngôn ngữ không an toàn khác, lại sẽ trông như được triển khai hoàn hảo ngay lập tức