2 điểm bởi GN⁺ 1 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Từ Claude Code v2.1.181, Bun được port sang Rust đã được nhúng sẵn, giúp tốc độ khởi động trên Linux nhanh hơn 10%, nhưng đa số người dùng hầu như không nhận ra thay đổi
  • Khi kiểm tra các chuỗi trong tệp thực thi, có thể xác nhận Bun v1.4.0 chưa có tag chính thức và đường dẫn tới các tệp mã nguồn Rust
  • Trong ~/.local/bin/claude, đã phát hiện 563 tên tệp .rs bao gồm src/runtime/bake/dev_server/mod.rs
  • Cũng có thể xác minh phiên bản nhúng là 1.4.0 bằng cách preload tệp TypeScript qua BUN_OPTIONS rồi in ra Bun.version
  • Bản Rust đã được phát hành dưới dạng Bun canary, và thông qua Claude Code hiện đã chạy production trên hàng triệu thiết bị

Bun nền tảng Rust được nhúng trong Claude Code

  • Theo Rewriting Bun in Rust, từ Claude Code v2.1.181 phát hành ngày 17/6 đã sử dụng bản port Rust
    • Tốc độ khởi động trên Linux được cải thiện 10%
    • Ngoài ra hầu như người dùng không nhận ra khác biệt, và Jarred Sumner đánh giá điều này là “Boring is good”
    • Thông qua Claude Code, nó đã chạy production trên hàng triệu thiết bị
  • Có thể tìm thấy phiên bản Bun nhúng từ các chuỗi trong tệp thực thi của Claude
strings ~/.local/bin/claude | grep -m1 'Bun v1'
  • Trên môi trường macOS arm64, đầu ra là Bun v1.4.0 (macOS arm64)
  • Khi đó bản phát hành chính thức mới nhất trên GitHub là Bun v1.3.14 ngày 12/5, nên có thể xem Claude Code đã bao gồm bản xem trước v1.4.0 chưa phát hành chính thức
  • Bản Rust đã được công bố dưới dạng Bun canary, và có thể cài bằng bun upgrade --canary

Mã nguồn Rust và xác minh phiên bản

  • Nếu trích xuất đường dẫn mã nguồn Rust từ tệp thực thi, có thể xác nhận 563 tên tệp
strings ~/.local/bin/claude | grep -Eo 'src/[[:alnum:]_./-]+\.rs'
  • Danh sách có các đường dẫn sau
src/runtime/bake/dev_server/mod.rs
src/runtime/bake/production.rs
src/bundler/bundle_v2.rs
  • Cách do Ajan Raj chia sẻ là preload một tệp TypeScript bằng BUN_OPTIONS để in trực tiếp Bun.version được nhúng trong Claude Code
cat > /tmp/bun-version.ts <<'EOF'
console.log("embedded bun:", Bun.version);
process.exit(0);
EOF
BUN_OPTIONS="--preload=/tmp/bun-version.ts" claude --version
  • Lệnh này cũng in ra 1.4.0
  • Trong commit ngày 17/5, phiên bản package.json đã được đổi thành 1.4.0 và giữ nguyên từ đó, nhưng vẫn chưa được đưa vào bản phát hành có tag nào ngoài canary

1 bình luận

 
Ý kiến trên Hacker News
  • Khó hiểu vì sao một TUI lại phải chạy qua JavaScript rồi React cho terminal. Việc Anthropic thậm chí mua lại cả runtime để cải thiện TUI càng khiến người ta nghi ngờ hơn về chất lượng kỹ thuật. Nếu việc viết lại dễ đến vậy thì chuyển Claude Code sang ngôn ngữ native hẳn sẽ rẻ hơn nhiều

    • Vì đây đã là một sản phẩm đang hoạt động tốt và tạo ra doanh thu khổng lồ, nên câu hỏi “tại sao lại chọn công nghệ này?” gần với lựa chọn kinh doanh hơn là lựa chọn kỹ thuật. Công nghệ được chọn ban đầu vẫn đang làm tốt vai trò của nó, nên dù kiến trúc không hoàn hảo cũng có ít lý do để thay đổi
      Ngay cả việc viết lại Bun cũng không hề dễ, và một công cụ phát triển không phải UI với hợp đồng API và test rõ ràng sẽ dễ đáng tin hơn sau khi viết lại so với công cụ UI có tính năng mơ hồ và thiếu test
    • Khi dùng Claude, OpenCode và Ghostty cùng lúc, các chương trình terminal tương tác tiêu tốn CPU và pin rất nặng, đến mức cả chiếc laptop vốn ở chế độ ngủ tiết kiệm qua đêm cũng nóng lên. Đã có hơn 40 năm tiền lệ từ curses/ncurses, Emacs, Vim, đến cả MS-DOS, nên thật khó hiểu vì sao lại cố nhét công nghệ web vào đây
    • Tôi từng đọc một bài viết nói rằng một công ty Haskell nổi tiếng đã chuyển sang Python vì tốc độ lặp phát triển nhờ LLM. Dữ liệu huấn luyện cho React là cực nhiều, và thời gian biên dịch TypeScript cũng ngắn hơn Rust v.v.
      Phần code hướng người dùng và tầng UX thay đổi nhanh có khả năng sẽ chuyển sang các hệ thống động cho phép lặp phát triển nhanh, còn tầng hạ tầng thì sẽ chuyển sang môi trường hệ thống an toàn như Rust. Java/C# nằm ở vùng trung gian, nhưng về sau có vẻ TypeScript/Python là đủ cho UX còn Rust phù hợp hơn cho công việc hệ thống, nên vị thế của chúng có thể sẽ thu hẹp
      https://avi.press/posts/2026-07-10-after-7-years-in-producti...
    • Nếu xem Anthropic đang dùng AI để viết Claude Code thì JavaScript cũng không phải lựa chọn tệ. Dữ liệu huấn luyện rất phong phú, lại tránh được các vấn đề đa luồng và quản lý bộ nhớ vốn có thể làm AI bối rối trong những ngôn ngữ hiệu năng cao khác, nên thuận lợi để dùng AI tạo phần mềm nhanh chóng
    • OpenAI đã quyết định viết lại Codex bằng Rust từ khoảng 1 năm trước. Nếu việc viết lại thực sự dễ như vậy thì cũng phải hỏi tại sao Bun lại cần thiết, và tại sao họ không chuyển toàn bộ mã JavaScript sang Rust
      https://github.com/openai/codex/discussions/1174
  • Đọc nguyên văn của Jarred thì có vẻ rất rõ rằng lý do chuyển đổi là những phần trước đây phải làm thủ công trong Zig nay được tự động hóa trong Rust. Cả con người lẫn agent đều không mang tính quyết định, nên nếu phải theo dõi thủ công vòng đời bộ nhớ và giải phóng tường minh trong Zig thì lỗi bỏ sót sẽ tích tụ rất lâu, còn Rust loại bỏ được lớp lỗi này nên là một sự đánh đổi tốt hơn về mặt quản trị kỹ thuật
    Đặc biệt, lỗi biên dịch từ compiler là rào chắn an toàn mang tính quyết định cần thiết cho coding agent, và khi giao cho Claude một cách kiểm tra tính đúng đắn cùng mục tiêu “hãy làm cho nó biên dịch được” thì nó hoạt động khá tốt. Cách tiếp cận tổng quát là biến đầu ra xác suất thành bảo đảm chắc chắn bằng các bài kiểm tra mang tính quyết định đã được tóm tắt tại https://michael.roth.rocks/blog/verification-surface/

    • Zig và C không phù hợp khi phải tạo nhiều cấp phát nhỏ có vòng đời không liên quan đến nhau. Muốn dùng một cách vững chắc thì phải tự quản lý vòng đời bằng cách gom cấp phát vào arena hoặc dùng buffer cố định
      Làm vậy thì Zig cũng có thể vững chắc không kém Rust, nhưng nếu muốn kiểu cấp phát theo phong cách ngôn ngữ managed mà LLM ưa thích thì Zig không phải lựa chọn phù hợp
    • Thứ xử lý tự động việc đó là ngôn ngữ garbage collection. Ngay cả trong Rust vẫn phải nghĩ và theo dõi vòng đời bộ nhớ, nhưng borrow checker sẽ ngăn cách xử lý sai và phản hồi sửa lỗi ngay lập tức, nên rất phù hợp để LLM viết. Việc tham số tham chiếu mặc định là bất biến cũng giúp ngăn nhiều vấn đề hiệu năng lớn
    • Hiện Bun có rất nhiều unsafe Rust, nên khó nói rằng nó tự động loại bỏ được cả một lớp lỗi: https://news.ycombinator.com/item?id=48967630
    • Theo kinh nghiệm của tôi, LLM bắt lỗi bộ nhớ khá dễ. Chuyện lần này trông chẳng khác gì một sự kiện marketing thành công của Anthropic
    • Tôi nhớ lần viết lại sang Rust này gần như toàn bộ là unsafe, nên rất có thể nó không tự động loại bỏ được vấn đề đó
  • Bất kể đánh giá của Jarred hay Simon Willison ra sao, tôi nhìn việc này khá tiêu cực. Vấn đề lớn hơn cả chuyện Anthropic mua Bun hay AI viết lại là cách làm thiếu chín chắn, bắt đầu từ thái độ “đó chỉ là branch của tôi thôi, các anh đang phản ứng quá mức” rồi hợp nhất một PR hơn 1 triệu dòng trong chưa đầy một tháng
    Họ giao tiếp cực kỳ tệ, làm xói mòn niềm tin và khoét sâu chia rẽ, và thật khó hiểu vì sao lại khó đến thế trong việc làm theo cách tiếp cận mà đội TypeScript đã áp dụng với 7.0

    • Cuối cùng thì có thể điều này không thực sự quan trọng, vì đa số người dùng Claude Code hoặc không nhận ra hoặc không quan tâm, còn phía phản đối chỉ là một thiểu số rất nhỏ
    • TS7 cũng là một ví dụ điển hình của việc dịch từng dòng sang ngôn ngữ khác thay vì nghiêm túc xem xét lại kiến trúc
  • Bun v1.4.0 đi kèm Claude có vẻ là một bản preview chưa được phát hành công khai. Nếu vậy thì có cảm giác dự án FOSS Bun đã âm thầm biến thành một thứ khác, nên thật may là tôi chỉ để việc điều tra vào TODO rồi không triển khai
    Tôi không tìm thấy tài liệu quản trị của Bun, nên tự hỏi liệu giờ đây trên thực tế Anthropic có phải là bên quyết định cả công việc lẫn việc merge hay không

    • Khó hiểu vì sao lại đi đến kết luận rằng chuyển sang Rust sẽ làm dự án chết đi
    • PR được công khai nên ai cũng có thể build và dùng, chỉ là đội Anthropic quyết định dùng trước mà thôi
    • Theo tôi hiểu thì trên thực tế vẫn phụ thuộc vào việc Jarred có muốn chấp nhận trong tuần đó hay không. Lịch sử thay đổi của Claude Code đã ghi thay đổi phiên bản Bun 1.4.0 từ gần một tháng trước, nhưng vì đó là lịch sử do AI viết nên việc hầu hết mọi người không đọc cũng không có gì lạ
    • Tôi cũng từng khảo sát việc dùng Bun nhưng đã quyết định không dùng vì độ bất ổn định, và nhìn lại chuyện này thì có vẻ đó là quyết định đúng đắn
  • Không rõ vì sao họ lại xử lý lòng vòng quanh Bun như vậy. Nếu agent có thể chuyển Zig sang Rust, thì Claude Code cũng có thể được viết lại trực tiếp bằng Rust từ JavaScript để loại bỏ phụ thuộc runtime và tăng hiệu năng

    • Nếu xem việc Bun được viết lại bằng Rust về cơ bản không liên quan gì đến chiến lược sản phẩm của Anthropic thì sẽ không có gì khó hiểu
    • Nếu chỉ xét riêng Claude Code thì viết lại trực tiếp bằng Rust có lẽ tốt hơn, nhưng như vậy giá trị thâu tóm Bun/oven.sh sẽ giảm đi đáng kể
      Ngoài Claude Code, Bun có lẽ còn có người dùng bên ngoài lẫn người dùng nội bộ tại Anthropic, đồng thời giúp họ nắm được một runtime JavaScript và hệ sinh thái công cụ mà các mô hình lập trình có thể ưa thích. Về sau Anthropic thậm chí có thể cung cấp cloud chuyên cho việc chạy và quản lý các ứng dụng kiểu này, và chỉ cần giành được cộng đồng nhà phát triển thôi cũng sẽ tạo ảnh hưởng lớn hơn nhiều so với việc chuyển riêng Claude Code sang Rust
    • Cũng đáng nghi liệu Claude Code có thực sự bị nghẽn hiệu năng hay không. Runtime JavaScript có hệ sinh thái công cụ lớn và phát triển plugin dễ dàng, nên hoàn toàn đủ phù hợp
  • Nếu bỏ qua suy đoán và cảm tính thì điều đáng tò mò là chất lượng vận hành thực tế. Không chỉ tốc độ khởi động mà còn phải kiểm tra mức dùng RAM·CPU, có vòng lặp vô hạn hay deadlock hay không; nếu vẫn như trước hoặc tốt hơn thì khá ấn tượng
    Với tư cách lập trình viên, tôi không thích khả năng AI cướp việc làm, nhưng nếu ai cũng có thể tạo ra phần mềm mình muốn chỉ bằng những yêu cầu đơn giản thì thế giới có thể tốt hơn. Nếu ghét việc Microsoft thu thập dữ liệu thì có thể nhờ AI làm hệ điều hành, nếu ghét Google nghe lén thì có thể nhờ AI làm điện thoại, tức có thể đạt tới tự chủ công nghệ; trước viễn cảnh đó thì sự ổn định việc làm của cá nhân trở nên nhỏ nhặt
    Vì vậy việc giữ công nghệ ở dạng mã nguồn mở lại càng quan trọng hơn, nếu không thì ta chỉ lặp lại cấu trúc độc quyền cũ trong khi còn mất cả việc làm

    • Phần khó nhất trong phát triển phần mềm là có được yêu cầu rõ ràng. Dù có AGI hoàn hảo thì con người vẫn không thể diễn đạt rõ điều mình muốn, nên sẽ không có chuyện xuất hiện một thế giới nơi ai cũng tạo được đúng phần mềm mình muốn
    • Công cụ tốt cũng phải do người thợ lành nghề sử dụng thì mới cho ra kết quả xuất sắc. Lập trình viên giỏi biết đặt câu hỏi phù hợp, dựng các cơ chế an toàn, và tự điều chỉnh kết quả ở những chỗ cần thiết
    • Gọi các mô hình đóng đang nằm sau tường phí được trợ giá hiện nay là dân chủ hóa công nghệ thì quá ngây thơ. Có vẻ chiến lược tận dụng việc Bun được chuyển sang Rust chủ yếu như một công cụ marketing đã phát huy tác dụng
  • Gần đây khi dùng Claude Code trong một tab Kitty, tôi gặp lỗi segmentation fault, sau đó cả tab không còn phản hồi với đầu vào nữa. Có hiện ra liên kết báo lỗi nhưng không thể bấm được, lại còn bị mã hóa nên cũng không biết đang gửi thông tin gì

    • Về ý tưởng và tính năng thì Bun vượt trội hẳn so với các runtime JavaScript khác, nhưng độ ổn định thì rất tệ, và số lần segmentation fault nhiều hơn Node khoảng 20 lần. Con số này dựa trên dữ liệu telemetry của New Relic
    • Nếu shell không in ra Segmentation fault thì nhiều khả năng không phải segmentation fault mà là bị treo. Nếu là lỗi thật thì sau khi quay về shell, dù không nhìn thấy trên màn hình, vẫn có thể gõ reset để khôi phục tab
    • Tôi dùng Ghostty và Claude Code trên MacBook công việc nhưng chưa gặp vấn đề này. Trước đây từng có rò rỉ bộ nhớ mất kiểm soát làm hệ thống treo và phải khởi động lại, nhưng vài tuần gần đây đã biến mất; còn quá sớm để khẳng định, nhưng có thể bản port Rust đã giảm rò rỉ bộ nhớ
    • Khi dùng giao diện câu hỏi tương tác của Claude trong Ghostty thì cũng bị treo tương tự, không nhận bất kỳ đầu vào nào kể cả chọn hay hủy, ngoài việc cuộn. Tuy vậy tôi không nghĩ nó liên quan tới Bun
    • Bản Zig cũng từng có segmentation fault, và nếu họ chuyển từng dòng sang unsafe Rust thì phần mã gây ra lỗi cũng vẫn còn nguyên. Sẽ không được giải quyết cho tới khi refactor sang Rust theo lối chuẩn và an toàn bộ nhớ
  • Họ trông giống như những kỹ sư thành công lớn nhưng tệ hại, rất giỏi mô tả vấn đề và có ngân sách token vô hạn. Nếu phải tự trả chi phí token thì hẳn đã có động lực tài chính để làm phần mềm hiệu quả hơn
    Thực tế bị che giấu của các trung tâm dữ liệu AI là ngay cả khi hiệu suất cụm GPU chỉ 40~60% thì họ cũng chỉ lấy tiền mua thêm thiết bị để bù vào. Lý do họ sợ đối thủ Trung Quốc có thể là vì họ không đủ dư dả để lãng phí như đối thủ

  • Lần này là một bản transpile, và chất lượng cũng không tốt. Mã được sinh ra rất xa với Rust theo lối chuẩn, đến mức có thể xem là xấu xí

    • Dù vậy có vẻ nó vẫn hoạt động ổn. Lần này về cơ bản chỉ là giai đoạn đầu chuyển từng dòng một cách cơ học, và ở bước tiếp theo họ dự định trau chuốt thành Rust theo lối chuẩn, nên tiếp tục cược ngược vào lần viết lại này có lẽ không phải ý hay
    • Nếu xét tới độ ổn định, hiệu quả và chi phí thì dùng hoặc tự viết một trình chuyển đổi liên ngôn ngữ để bảo toàn tối đa cấu trúc gốc sẽ hợp lý hơn nhiều
      Thông thường khi viết lại, người ta phản ánh các bài học rút ra từ codebase cũ, nhưng nếu dùng agent để chuyển từng file thì không có lợi ích đó. Dù theo cách nào cũng sẽ thành một bản dịch không theo lối chuẩn, nhưng dùng LLM còn bổ sung thêm tính không xác định và chi phí khổng lồ
    • Cần có ví dụ cụ thể về đoạn mã Rust bị cho là xấu xí đó
    • Không hiểu vì sao họ không transpile thẳng sang LLVM IR
    • Nếu dự án đạt được mục tiêu an toàn bộ nhớ thì việc mã có theo lối chuẩn hay không liệu có thực sự quan trọng đến thế không cũng là điều đáng hỏi
  • Gần đây Claude Code bất ổn hơn nhiều so với trước, và lỗi render TUI thường xuyên làm hỏng lịch sử hội thoại

    • Tôi miễn cưỡng dùng Claude từ tháng 2, và ngay từ đầu nó đã là TUI tệ nhất tôi từng dùng với lỗi render, lỗi nhập bàn phím và đủ thứ khác. Thế mà trong khoảng một tuần gần đây nó còn tệ hơn nữa, đến mức vài ký tự đã nhập không hiển thị và thậm chí bắt đầu phá cả phiên terminal
      Gửi nó xuống background, chạy reset, rồi đưa lại foreground thì sẽ sửa được. Khi nhờ Claude chẩn đoán, nó nói bản thân không có lỗi đó và là do chương trình khác, nhưng lúc ấy chỉ chạy tmux và Claude. Nếu gần đây họ áp dụng bản Rust thì thời điểm chất lượng giảm sút cũng khá trùng khớp
    • Trên Windows, mỗi lần đổi kích thước cửa sổ thì đầu ra bị vỡ hoàn toàn và tôi phải yêu cầu lại câu trả lời vừa rồi. Không phải vấn đề mới, nhưng có cảm giác gần đây còn tệ hơn
    • Tôi không phản đối bản thân AI, nhưng Anthropic đã đi quá xa khi tung ra mã chất lượng thấp do AI tạo ra. Kỹ sư thực vẫn phải tiếp tục can thiệp để dẫn dắt công cụ, nhưng Anthropic có vẻ muốn giao 100% mã cho AI