Viết lại Bun bằng Rust

 (bun.com)
4 điểm bởi GN⁺ 5 ngày trước | 2 bình luận | Chia sẻ qua WhatsApp
  • Bun, khởi đầu bằng Zig, đã phát triển thành runtime được tải xuống hơn 22 triệu lần mỗi tháng, nhưng việc kết hợp engine JavaScript dựa trên GC với quản lý bộ nhớ thủ công đã gây ra các vấn đề ổn định lặp lại, trở thành động lực để chuyển sang Rust
  • Thay vì để con người chuyển 535.496 dòng mã Zig trong 1 năm, nhóm đã chạy song song khoảng 50 workflow động của Claude Code và tối đa 64 instance Claude trong 11 ngày
  • Quá trình port được kiểm chứng bằng PORTING.md, LIFETIMES.tsv, 1 người triển khai cùng ít nhất 2 reviewer đối kháng, và bộ test TypeScript hiện có; tất cả đều pass 100% trên CI của 6 nền tảng
  • Sau khi chuyển sang Rust, Bun v1.4.0 đã sửa 128 lỗi tái hiện được ở v1.3.14, khắc phục toàn bộ rò rỉ bộ nhớ có thể instrumentation, và giảm kích thước binary trên Linux·Windows khoảng 20%
  • Bun v1.3.14 là phiên bản Zig cuối cùng, còn v1.4.0 là phiên bản Rust đầu tiên được cung cấp trên canary; nhóm dùng borrow checker, Miri, LeakSanitizer và fuzzing dựa trên coverage 24/7 làm công cụ cải thiện độ ổn định

Bun khởi đầu bằng Zig và vấn đề ổn định

  • Bun bắt đầu là dự án port từng dòng transpiler JavaScript·TypeScript của esbuild từ Go sang Zig
  • Mã Zig đầu tiên được viết vào ngày 16/4/2021, và khả năng kiểm soát cấp thấp cùng thiết kế hướng hiệu năng của Zig đã giúp hiện thực hóa bản triển khai Bun ban đầu
  • Bun giai đoạn đầu được một người viết bằng Zig trong 1 năm, với phạm vi rất rộng
    • Transpiler·minifier·bundler cho JavaScript, TypeScript, CSS
    • Trình quản lý package tương thích npm
    • Test runner tương tự Jest
    • Phân giải module tương thích Node.js·TypeScript
    • Client HTTP/1.1·WebSocket
    • Triển khai các API Node.js như fs, net, tls
  • Hiện Bun CLI được tải xuống hơn 22 triệu lần mỗi tháng, được Claude Code và OpenCode dùng làm runtime, và được Vercel, Railway, DigitalOcean cùng các bên khác hỗ trợ first-party

Các lỗi an toàn bộ nhớ lặp lại

  • Các ví dụ lỗi được sửa trong Bun v1.3.14 bao gồm use-after-free, double-free, rò rỉ bộ nhớ, truy cập out-of-bounds và race condition
    • Heap-use-after-free do gọi .reset() trong lúc async .write() của node:zlib
    • Use-after-free trong node:http2 khi callback JS tái nhập gây rehash hashmap, làm vô hiệu hóa con trỏ stream nội bộ
    • Vấn đề callback valueOf() hoặc toString() detach ArrayBuffer trong UDPSocket.send() và sendMany()
    • Crash và out-of-bounds read trong Buffer#copy, Buffer#fill do ArrayBuffer bị detach hoặc resize trong quá trình coercion đối số
    • Rò rỉ bộ nhớ liên quan đến crypto.scrypt, tlsSocket.setSession(), fs.watch()
    • Double-free khi CSS parser xử lý vendor prefix và background nhiều lớp
    • Crash do race condition MessageEvent khi truy cập đồng thời BroadcastChannel hoặc MessagePort
  • Trước đây nhóm cũng đã dùng nhiều cơ chế để tăng cường độ ổn định
    • Patch hỗ trợ Address Sanitizer vào Zig compiler và chạy bộ test ASAN trên mọi commit
    • Phát hành bản build ReleaseSafe có kiểm tra an toàn của Zig cho Windows
    • Fuzz API runtime của Bun 24/7 bằng Fuzzilli
    • Vận hành nhiều test rò rỉ bộ nhớ end-to-end
  • Lập trường không phải Zig tự thân là vấn đề; nguồn chính của vấn đề ổn định là yêu cầu phải xử lý đồng thời giá trị GC và bộ nhớ quản lý thủ công

Lý do chọn Rust

  • JavaScript là ngôn ngữ GC, và các engine như JavaScriptCore và V8 có quy tắc nghiêm ngặt về xử lý exception và GC
  • Zig không tự động quản lý bộ nhớ như C, không có constructor·destructor, và cleanup phần lớn phải được chỉ định rõ bằng defer tại từng call site
  • Trong Bun, việc xử lý đúng lifetime của giá trị GC và giá trị quản lý thủ công là một nguồn lớn gây ra vấn đề ổn định
    • Phải xác nhận byte đã cấp phát được giải phóng ở đâu
    • Phải đảm bảo chỉ được giải phóng một lần
    • Phải kiểm tra đúng cách việc xử lý exception JavaScript
    • Phải xác nhận con trỏ GC có hiển thị với conservative stack scanner hay không
  • Cách cleanup của Zig là defer, errdefer tường minh; C++ dùng destructor và move, còn Rust dùng Drop
  • Trong mã Zig hiện có của Bun, arena lifetime, reference counting và review cẩn thận được kết hợp với nhau
  • Cũng có thể cưỡng chế quy tắc ownership bằng style guide và code review, nhưng trong mã Rust an toàn, use-after-free, double-free và free bị thiếu trên error path sẽ trở thành lỗi trình biên dịch
  • Khoảng 20% mã của Bun là C++ và nhúng nhiều thư viện C/C++
    • JavaScriptCore
    • uWebSockets và usockets
    • lshpack và lsquic
    • BoringSSL
    • SQLite
  • C++ cũng có thể là một lựa chọn, nhưng vẫn phụ thuộc vào style guide và code review; ngay cả khi có ASAN, hỏng bộ nhớ và rò rỉ vẫn có thể xảy ra

Chiến lược viết lại: một lần, theo kiểu cơ học

  • Mã Zig hiện có của Bun có 535.496 dòng không tính chú thích, và một lần viết lại theo cách truyền thống được đánh giá là công việc mất khoảng 1 năm với một nhóm kỹ sư nhỏ
  • Vì không thể dừng sửa lỗi, vá bảo mật và phát triển tính năng trong 1 năm, port cơ học nhằm giảm thiểu thay đổi hành vi với người dùng được chọn làm cách tiếp cận ít rủi ro nhất
  • Bộ test của Bun được viết bằng TypeScript nên không phụ thuộc vào ngôn ngữ triển khai runtime
  • Viết lại tăng dần được đánh giá là đau đớn trong ngắn và trung hạn vì phải tạo mã tạm và kỳ vọng sẽ xóa sau này, nên nhóm chuyển toàn bộ một lần
  • Mã Rust được viết để trông như được transpile từ mã Zig, và hướng đi được chọn là sau Bun v1.4 sẽ giảm dần unsafe rồi refactor theo Rust idiomatic

Workflow động của Claude Code

  • Trong lần viết lại bằng Rust, khoảng 50 workflow động trên Claude Code đã chạy liên tục trong 11 ngày
  • Các workflow trải dài từ viết hướng dẫn port, chuyển đổi file, sửa lỗi biên dịch, khôi phục subcommand, vượt qua toàn bộ test, cho đến cleanup quy mô lớn
    • Tạo hướng dẫn port ánh xạ các pattern và type của Zig sang pattern và type của Rust
    • Port cơ học mọi file .zig thành file .rs theo PORTING.md và LIFETIMES.tsv
    • Sửa lỗi compiler theo từng crate
    • Khôi phục hoạt động của các subcommand như bun test, bun build
    • Pass toàn bộ bộ test
    • Refactor và cleanup quy mô lớn
  • Trong phần lớn thời gian, con người đọc đầu ra của workflow, kiểm tra vấn đề và lỗi, rồi điều chỉnh prompt để Claude sửa vòng lặp
  • Trong phần chuẩn bị, nhóm đã thảo luận khoảng 3 giờ với Claude về cách ánh xạ các pattern trong codebase Zig sang Rust, và kết quả được tuần tự hóa thành PORTING.md
  • Để thêm Rust lifetime vào mã quản lý bộ nhớ thủ công, nhóm chạy workflow phân tích lifetime của mọi struct field
    • Tìm các field có lifetime phức tạp
    • Đề xuất lifetime
    • 2 agent review đối kháng kiểm tra
    • Phản hồi được phản ánh và lưu vào LIFETIMES.tsv

Phương thức review đối kháng

  • Với mỗi Claude triển khai, đặt một Claude reviewer đối kháng trong một context window riêng; reviewer chỉ nhận diff và được chỉ thị giả định rằng code sai để tìm bug
  • Cấu trúc cơ bản gồm 1 người triển khai, 2 reviewer đối kháng trở lên và 1 fixer
  • Tất cả bug mà reviewer thực sự bắt được đều vượt qua biên dịch nhưng có vấn đề về hành vi
    • uv_close là bất đồng bộ nhưng Box<uv::Pipe> bị drop ở cuối match arm, khiến libuv giữ freed memory, dẫn đến use-after-free và double-free
    • Lỗi timespec khi dùng trunc() với file time âm không nguyên, tạo ra nsec âm
    • Lỗi unwrap_or đánh giá eager đối số, gây panic trong trường hợp lược bỏ percentage của color-mix()
  • Giống như review của con người, tách context của tác giả và reviewer để giảm thiên lệch có thể phát sinh do người triển khai muốn merge

Thực thi port quy mô lớn và song song hóa

  • Trước khi chuyển toàn bộ 1.448 file .zig, họ xác minh quy trình trước bằng 3 file
    • 1 người triển khai viết file .rs
    • 2 reviewer kiểm tra xem hành vi có khớp với .zig và có tuân theo PORTING.md, LIFETIMES.tsv hay không
    • 1 fixer áp dụng các đề xuất
  • Ở giai đoạn đầu port toàn bộ file, nhiều Claude chạy git stash, git stash pop, git reset HEAD --hard và xung đột lẫn nhau
  • Sau đó họ thêm vào workflow các quy tắc cấm git stash, git reset, các lệnh git không phải commit file cụ thể, và các lệnh chậm như cargo
  • Cuối cùng, họ dùng 4 workflow shard và 4 worktree; trong mỗi shard, 16 Claude commit và push file
  • Nhờ song song hóa và chuẩn bị trước, ở mức peak Claude viết khoảng 1.300 dòng code mỗi phút
  • Nhánh port có 6.502 commit không tính các commit merge, giờ peak đạt 695 commit, và landed diff cuối cùng là +1.009.272 dòng
  • Do không tăng IOPS mặc định của instance EC2, chỉ một lệnh grep chậm cũng khiến đọc/ghi đĩa bị dừng trong vài phút

Lỗi biên dịch và tách crate

  • Sau khi viết xong toàn bộ code, workflow Claude sửa lỗi compiler
  • Codebase Zig thực chất là một compilation unit duy nhất, còn code Rust dự kiến được chia thành khoảng 100 crate để biên dịch nhanh hơn
  • Nhóm lỗi khó nhất là phụ thuộc vòng
    • Chỉ PR tách crate ngay trước khi viết lại bằng Rust là chưa đủ
    • Một workflow riêng phân loại và ghi lại nên đặt code có phụ thuộc vòng ở đâu
    • Một workflow khác thực hiện phần refactor đó
  • Sau khi xử lý phụ thuộc vòng, khoảng 16.000 lỗi compiler lộ ra
  • Các lỗi này được xử lý song song theo từng crate
    • Chạy cargo check trong từng crate
    • Gom output theo file và lưu lại
    • Sửa lỗi biên dịch của crate đó
    • 2 reviewer đối kháng review thay đổi
    • 1 fixer áp dụng sửa đổi
  • Cũng có một false start khi Claude diễn giải “hãy làm cho tất cả crate biên dịch được” thành việc tạo function stub
  • Khi xuất hiện pattern biện minh workaround bằng các chú thích giải thích dài, họ thêm quy tắc review: “nếu cần comment dài cỡ một đoạn văn thì code đã sai và cần sửa code”

Quá trình đến khi pass test

  • Sau khi cargo check pass, họ lần lượt xử lý lỗi link, panic ngay sau khi khởi động, chạy bun --version, rồi bun test <file>
  • Họ dùng workflow lưu stacktrace thất bại theo từng CLI subcommand vào file, rồi sửa qua vòng lặp triển khai–reviewer–fixer
  • Workflow cho file test shard khoảng 100 file test ngẫu nhiên vào 4 worktree, lưu stacktrace và lỗi theo từng thất bại rồi sửa
  • Bộ test có các bài kiểm tra rò rỉ bộ nhớ và test tích hợp có thể timeout trong debug build
    • Test chạy next dev và hot module reloading phát hiện 100 thay đổi
    • Stress test làm cạn số lượng TCP socket tối đa
    • Test đọc/ghi đĩa ở quy mô gigabyte
    • Test spawn khoảng 10.000 process
  • Để cô lập, họ dùng systemd-run và cgroups để giới hạn mức dùng bộ nhớ/CPU và tách pid namespace
  • Dù vậy, máy vẫn crash nhiều lần do hết dung lượng đĩa
  • Hai ngày sau lần chạy CI đầu tiên, số file test thất bại giảm từ 972 xuống 23; một ngày rưỡi sau đó Linux hoàn toàn green
  • Cuối cùng, toàn bộ test CI trên 6 nền tảng đều pass
    • macOS x64
    • macOS arm64
    • Linux x64
    • Linux arm64
    • Windows x64
    • Windows arm64
  • Sau khi test pass 100%, con người kiểm tra thủ công rằng test thực sự được chạy và không bị skip, rồi merge
  • Thời điểm merge vào main không phải là một versioned release; họ chưa đủ tự tin để release, nhưng đã đủ tự tin để dồn sức cho rewrite

Quy mô test và chi phí

  • Trong 11 ngày, từ ngày 3/5 đến khi merge ngày 14/5, 6.778 commit được tạo ra
  • Test không bị xóa hoặc skip
  • Quy mô test theo nền tảng như sau
    • Debian 13 x64: expect() 1.386.826 lần, 60.624 test, 4.174 file
    • macOS 14 arm64: expect() 1.259.953 lần, 58.850 test, 4.175 file
    • Windows 2019 x64: expect() 1.007.544 lần, 57.337 test, 4.173 file
  • Công việc pre-merge dùng 5,9 tỷ uncached input token, 690 triệu output token và 72 tỷ cached input token read
  • Chi phí theo giá API vào khoảng 165.000 USD
  • Họ đánh giá rằng nếu con người tự làm thì 3 kỹ sư có context toàn bộ codebase sẽ mất khoảng 1 năm
  • Model được dùng là pre-release Claude Fable 5, và có disclosure rằng Bun đã được Anthropic mua lại vào tháng 12/2025

Review bảo mật, fuzzing và tình trạng unsafe

  • Sau khi merge bản port Rust, họ hoàn tất 11 vòng review bảo mật bằng Claude Code Security và xử lý các finding
  • Fuzzing dựa trên coverage chạy 24/7 được thêm cho tất cả parser của Bun
    • JavaScript
    • TypeScript
    • JSX
    • CSS
    • JSON5
    • JSONC
    • TOML
    • YAML
    • Markdown
    • INI
    • Bun Shell scripts
    • semver ranges
    • file .patch
    • CSS colors
  • Fuzzer gửi bug tìm được cho Claude để Claude nộp PR bao gồm tái hiện và bản sửa; con người review PR
  • Đến nay, parser đã được chạy 100 tỷ lần và dẫn tới khoảng 15 PR
  • Tại thời điểm viết, khoảng 4% code Rust nằm trong block unsafe
    • Khoảng 13.000 keyword unsafe
    • Khoảng 27.000 dòng / tổng khoảng 780.000 dòng
    • 78% block unsafe là một dòng, là con trỏ đến từ C++ hoặc lời gọi thư viện C
  • Họ cho biết vì vẫn tiếp tục dùng các thư viện C/C++ như JavaScriptCore, lượng unsafe sẽ luôn nhiều hơn so với dự án Rust thuần

Regression được phát hiện sau khi chuyển sang Rust

  • Rust rewrite là một thay đổi quy mô lớn nên đã tạo ra 19 regression đã biết, và tất cả đều đã được sửa
  • Phần lớn đến từ những đoạn code có cú pháp tương tự giữa hai ngôn ngữ nhưng ngữ nghĩa khác nhau

  • Side effect bên trong debug_assert!

    • assert của Zig là hàm nên các đối số được thực thi trong mọi build
    • debug_assert! của Rust là macro nên trong release build, toàn bộ biểu thức bị loại bỏ
    • Lời gọi insert_stale biến mất trong release build, làm hỏng một số trường hợp HMR cụ thể của dự án HTML route dùng React
    • Issue liên quan: #30678

  • Slice có độ dài lẻ

    • Zig helper reinterpretSlice(u16, bytes) của Bun dùng @divTrunc nên đã bỏ qua trailing odd byte
    • bytemuck::cast_slice của Rust sẽ panic khi độ dài là lẻ
    • Đã có regression khiến Blob.text() với các byte lẻ sau UTF-16 BOM không trả về chuỗi mà làm process panic
    • Cách sửa là bỏ qua odd byte trở lại bằng &buf[..buf.len() & !1]
    • Issue liên quan: #31188

  • Bounds checks

    • Code Zig trên macOS và Linux được compile bằng ReleaseFast nên bounds check bị loại bỏ, còn Rust release build vẫn giữ bounds check
    • Kích thước overflow block của Bun module resolver vẫn để placeholder 64, làm ceiling giảm từ 8,4 triệu interned filenames xuống 270.272
    • Lỗi off-by-one ptrs[4095] được port sang trở nên có thể chạm tới trong dự án thực tế, và Rust panic thay vì ghi out-of-bounds
    • Issue liên quan: #31503

  • Format string comptime

    • Trong Output.pretty của Zig, fmt là comptime nên các color marker <r>, <d> được chuyển thành ANSI escape trước khi thay thế đối số
    • Hàm Rust không có comptime parameter nên xử lý marker trên chuỗi đã hoàn chỉnh, và rewrite nhầm cả đối số
    • Trong bun update -i, OSC 8 hyperlink termination xung đột với trailing marker <r>, khiến r được in ra như văn bản
    • Với Rust cần dùng macro bun_core::pretty!("<r>{}<r>", hyperlink)
    • Issue liên quan: #30693

Các bug đã sửa và rò rỉ bộ nhớ

  • Bun v1.4.0 sửa 128 bug có thể tái hiện trong v1.3.14
  • Phạm vi bao gồm rò rỉ bộ nhớ, crash, cho đến help text bị tô màu sai
  • Drop của Rust tự động gọi hàm drop khi giá trị ra khỏi scope
  • Trong Zig, phải thêm defer ở từng call site, nên dễ bị thiếu cleanup hoặc cleanup trùng lặp
  • Drop của Rust là lựa chọn chấp nhận hidden control flow để đổi lại việc giảm các footgun phổ biến
  • Drop đã sửa nhiều rò rỉ bộ nhớ liên quan đến file path trong error handling code
  • Tích hợp LeakSanitizer của Bun được cải thiện, theo dõi tất cả native code memory allocations
  • Tất cả instrumentable memory leak đều đã được sửa

  • Cải thiện rò rỉ trong Bun.build()

    • Trong Bun v1.3.14 trước đây, mỗi lần gọi in-process Bun.build(), parsed source text và AST symbol table tồn tại lâu hơn vòng đời build, gây rò rỉ vài MB mỗi lần
    • Trong bài test bundle cùng một dự án 60 module 2.000 lần trong một process, v1.3.14 tiếp tục rò rỉ khoảng 3MB mỗi build
    • Trong Bun v1.4.0, mức sử dụng bộ nhớ đi ngang
    • | Builds | Bun v1.3.14 | Bun v1.4.0 |
    • | --- | ---: | ---: |
    • | 500 | 1.914 MB | 526 MB |
    • | 1.000 | 3.506 MB | 586 MB |
    • | 1.500 | 5.097 MB | 608 MB |
    • | 2.000 | 6.745 MB | 609 MB |

Kích thước binary, mức dùng stack, hiệu năng

  • Chỉ với thay đổi ban đầu của Rust rewrite, kích thước binary đã giảm
    • Windows: giảm 3,8 MB
    • macOS: giảm 5,5 MB
    • Linux: giảm 6,8 MB
  • Nguyên nhân chính là code Zig đã dùng comptime quá nhiều
  • Sau đó cũng áp dụng identical code folding, loại bỏ unused data của ICU, và cách lazy decompress một phần libicu bằng zstd dictionary
  • Kết hợp Rust rewrite, thay đổi ICU và identical code folding, kích thước binary Bun trên Linux và Windows giảm khoảng 20%
Version Platform Size
Bun v1.4.0 canary Windows 76 MB
Bun v1.3.14 Windows 94 MB
Bun v1.4.0 canary Linux 70 MB
Bun v1.3.14 Linux 88 MB
  • TOML parser và các recursive-descent parser của Bun dùng ít stack space hơn
  • LLVM IR codegen của Rust phát ra các intrinsic llvm.lifetime.start và llvm.lifetime.end cho stack variable, giúp LLVM tái sử dụng stack slot
  • Trước đây, để обход qua open issue của Zig, họ phải tự refactor các hàm đặc biệt lớn thành nhiều hàm nhỏ hơn
  • Rust hỗ trợ cross-language link-time optimization giữa C/C++ và Rust, cho phép inlining giữa các ngôn ngữ

  • Benchmark Linux x64

    • So sánh Bun v1.3.14 và Bun v1.4.0 trên Linux x64 EC2 Xeon Platinum 8488C
    • HTTP throughput được đo bằng oha, app workload được đo bằng hyperfine
    • | server | Bun v1.3.14 | Bun v1.4.0 | Δ |
    • | --- | ---: | ---: | ---: |
    • | Bun.serve | 169,6k req/s | 177,7k req/s | +4,8% |
    • | node:http | 103,8k req/s | 108,5k req/s | +4,5% |
    • | Elysia | 158,9k req/s | 163,3k req/s | +2,8% |
    • | express | 64,5k req/s | 66,6k req/s | +3,2% |
    • | fastify | 91,5k req/s | 95,9k req/s | +4,8% |
    • | workload | Bun v1.3.14 | Bun v1.4.0 | Δ |
    • | --- | ---: | ---: | ---: |
    • | next build | 13,62 s | 13,03 s | +4,5% |
    • | vite build | 1,69 s | 1,65 s | +2,2% |
    • | tsc -b --force | 0,94 s | 0,89 s | +4,7% |

Các trường hợp sử dụng thực tế và trạng thái phát hành

  • Prisma đã ra mắt public beta của Prisma Compute trên nền bản rewrite Rust của Bun
  • Phía Prisma cho biết họ đã kiểm thử trên bản rewrite Rust các failure mode gồm connection pool không khôi phục sau khi VM pause/resume và memory leak, và bản rewrite đã xử lý tốt các failure mode này
  • Claude Code v2.1.181 và các phiên bản sau bản phát hành ngày 17 tháng 6 sử dụng Bun được port sang Rust
  • Startup trên Linux của Claude Code nhanh hơn 10%, còn ngoài ra hầu hết người dùng gần như không nhận ra khác biệt
  • Bun v1.3.14 là phiên bản Bun cuối cùng được viết bằng Zig
  • Bun v1.4.0 là phiên bản Bun đầu tiên được viết bằng Rust và được cung cấp dưới dạng canary

Công cụ đội ngũ thu được và những việc còn lại

  • Codebase Rust mới vẫn giữ hình thái rất giống codebase Zig hiện có
  • Được viết để những người hiểu mã Zig ban đầu cũng có thể hiểu được mã Rust được dịch một cách cơ học
  • Việc review PR rewrite Rust được tiến hành bằng cách kiểm tra xem agent review đối nghịch có phát hiện đúng các điểm không nhất quán giữa Zig và Rust, hướng dẫn porting, và việc tuân thủ lifetime guide hay không, đồng thời con người đọc nhiều đoạn mã theo kiểu side-by-side
  • Bun v1.4 giúp Bun nhanh hơn, nhỏ hơn, giảm mức sử dụng bộ nhớ và cung cấp công cụ để cải thiện độ ổn định
    • Rust borrow checker
    • Miri
    • LeakSanitizer
    • coverage-guided fuzzing 24/7 cho parser
  • Vẫn còn những phần cần refactor, và bun-unsafe-audit đã được kết nối
  • Một kỹ sư đã theo dõi sát sao Fable và Claude Code, đạt tới trạng thái toàn bộ test suite pass trên mọi nền tảng chỉ trong 11 ngày

Bài viết liên quan

2 bình luận

 
GN⁺ 5 ngày trước
Các ý kiến trên Hacker News

  • Bài viết này cho thấy khá rõ rằng việc tự động viết lại đã có kỷ luật và sự cẩn trọng, cũng như có sự can thiệp của con người; nó tạo cảm giác rằng họ đã tiến hành một cách nghiêm túc nhất có thể với AI
    Riêng tôi thì không hiểu lắm vì sao đến năm 2026 rồi mà vẫn không muốn dùng một ngôn ngữ an toàn bộ nhớ và nếu có thể thì an toàn cả trước điều kiện cạnh tranh
    Rust cung cấp điều đó mà vẫn có hiệu năng, nên dù không thích garbage collection hay tính bất biến vì lý do hiệu năng, vẫn có lựa chọn là Rust
    Tôi hiểu các trường hợp phải xuống C++ vì tuyệt đối cần hiệu năng cao nhất, hoặc do sở thích cá nhân, nhưng ngoài ra thì Rust gần như là lựa chọn hiển nhiên

    • Trình biên dịch Rust rất chậm. Cách tốt nhất để tăng tốc có vẻ là chia codebase thành nhiều crate, nhưng với nhiều người đó không phải là trải nghiệm phát triển tốt
      Hơn nữa, trong nhiều bài toán, garbage collector loại bỏ được nhiều lỗi, kể cả những lỗi được nêu trong bài, mà không tạo thêm ma sát; còn Rust thì yêu cầu phải suy nghĩ theo góc nhìn quyền sở hữu
      Ví dụ, nhiều lập trình viên game thích lặp nhanh bằng các ngôn ngữ ít ma sát. Mã game có thể khó nhằn như mã UI frontend, quy trình build cũng có thể rất đặc thù, và thường lặp phát triển bằng hot reloading
      Bảo họ dùng một trình biên dịch chậm đồng nghĩa với việc chấp nhận thêm độ trễ trong vòng lặp đó. Tất nhiên tôi không cho rằng các lý do này áp dụng cho tất cả mọi người
    • “Sự can thiệp của con người” ư, thật mỉa mai nếu đây là một dự án đã thành công trong việc loại bỏ cả sự can thiệp của con người trong quá khứ lẫn tương lai
    • Người ta gắn bó với những thứ họ đã dùng suốt hàng chục năm. Ngoài ra, phần lớn thế giới vẫn được viết bằng C/C++, nên để vượt qua khối lượng tới hạn thì còn rất nhiều thứ phải đối đầu
      Rust không hoàn hảo, nhưng giải quyết được nhiều cạm bẫy của C++. Không chỉ hành vi không xác định, mà cả quản lý package, các file CMake kinh khủng, lỗi linker, v.v.
    • Chuyển từ Rust sang C++ có vẻ là một lựa chọn kỳ lạ. Vì gần như vẫn gặp cùng các vấn đề mà lại mất đi an toàn bộ nhớ
      Zig, Odin, C3, thậm chí C cũ kỹ, ít nhất đều có những ưu điểm mà cả Rust lẫn C++ không có. Dù đó chỉ là tốc độ biên dịch đi nữa
    • Mỗi lần nhìn dung lượng đĩa cần cho build Rust là tôi lại ngạc nhiên. Nếu nhớ không nhầm, biên dịch Zed tốn hơn 50GB

  • Điều quan trọng là cách này rẻ hơn rất nhiều so với thuê một đội kỹ sư phần mềm. Dù có thuê tôi với giá 200.000 USD, tôi nghĩ trong vòng một năm tôi cũng không làm được việc này
    Tôi không có ngữ cảnh, cũng không biết Zig hay Rust; có thể học được trong một tháng, nhưng sẽ rất chậm
    Ngay cả bỏ qua các dự đoán kiểu điểm kỳ dị, chỉ với AI hiện nay thôi thì việc biện minh cho chuyện thuê một kỹ sư phần mềm 200.000 USD cũng sẽ trở nên khó khăn
    Ở tầng cao nhất của các công ty lấy phần mềm làm trung tâm như Google hay Anthropic, họ vẫn sẽ tuyển các kỹ sư giỏi để tạo ra phần mềm mới mà AI hiện chưa làm tốt; nhưng với các công ty như Walmart hay Target, nơi phần mềm chỉ là một trung tâm chi phí, hoặc các công ty vốn đã outsource phát triển hay dùng nhân lực H1B giá rẻ, sẽ xuất hiện một phương án AI tốt hơn nhiều so với kỹ sư trung bình
    Khoảng 1,6 triệu lập trình viên phần mềm ở Mỹ rất có khả năng sẽ giảm mạnh. Nhóm đỉnh cao cỡ L6 ở FAANG sẽ ổn, nhưng lập trình viên trung bình ở một ngân hàng vô danh hay người làm website cho McDonalds sẽ phải học thứ khác, nếu không có thể sớm mất việc
    Một năm trước tôi đã không dự đoán như vậy, nhưng giờ thì có vẻ rõ ràng rằng thay đổi này sẽ xảy ra

    • “Trong kinh tế học, nghịch lý Jevons xảy ra khi các cải tiến công nghệ làm tăng hiệu quả sử dụng một tài nguyên lại làm tổng mức tiêu thụ tài nguyên đó tăng lên thay vì giảm xuống. Khi hiệu quả tăng, lượng tài nguyên cần cho mỗi ứng dụng giảm, làm chi phí thực tế thấp hơn; nếu nhu cầu đủ co giãn theo giá, nhu cầu sẽ được kích thích và tổng mức tiêu thụ tài nguyên thường tăng ròng”
      https://en.wikipedia.org/wiki/Jevons_paradox
    • Việc một kỹ sư trị giá 200.000 USD phù hợp với công việc đó có thể không mang lại giá trị lớn hơn hay không là điều hoàn toàn còn gây tranh luận
      Ngoài ra, liệu công việc này có thực sự tạo ra giá trị hay không cũng còn gây tranh luận. Ai từng dùng unsafe Rust và cũng từng dùng Zig sẽ biết rằng so sánh ra thì unsafe Rust nguy hiểm hơn nhiều
    • Tôi không bi quan đến vậy. Có vô hạn việc có thể làm. Trước đây, ý tưởng viết lại dự án bằng Rust có lẽ chẳng ai coi là nghiêm túc
      Nó cũng không thực sự thay thế việc làm nào, và rốt cuộc để làm được việc này vẫn phải thuê một kỹ sư lương cao
      Tôi cho rằng khả năng lớn là nó sẽ tạo ra nhiều thay đổi mã hơn, thay vì khiến tuyển ít người hơn
    • Tôi lại nhìn theo hướng ngược lại. Những thay đổi trên phạm vi rộng như thế này chỉ có thể giao cho kỹ sư senior
      Giờ đây có khả năng người ta sẽ muốn thuê thêm các kỹ sư senior có thể thực sự thực hiện được những thay đổi như vậy
    • Không chỉ vậy. Kể cả tác giả, phần lớn mọi người hẳn đã không nghĩ rằng việc này thực sự khả thi
      Không chỉ thời gian và chi phí bỏ ra thấp hơn dự đoán của nhiều người, mà còn có thể kỳ vọng rằng trong tương lai gần, mức độ tương tác của con người, sai sót, thời gian và chi phí như thế này sẽ giảm thêm 2 lần, 5 lần, thậm chí hơn 10 lần
      Cũng phải tính đến việc bản thân bài blog đóng vai trò như tài liệu quảng bá cho Claude và LLM nói chung

  • Dù không bàn đến bản thân dự án Bun hay bản chất của việc viết lại, nếu chỉ một lần viết lại theo kiểu ngây thơ để rời khỏi Zig mà đã sửa được rò rỉ bộ nhớ, cải thiện độ ổn định, giảm kích thước binary 20% và tăng hiệu năng 5%, thì điều đó không thể khiến Zig trông tốt hơn

    • Tôi không nghĩ việc xếp chuyện này vào nhóm “một lần viết lại ngây thơ để rời khỏi Zig” là công bằng. Jarred đã chìm sâu trong dự án này suốt 5 năm, tận dụng mọi thứ học được trong thời gian đó, và đã chi 165 nghìn USD tiền token cho LLM lập trình tiên tiến nhất mà ai cũng có thể tiếp cận
      Nếu chạy Fable trị giá 165 nghìn USD trên phiên bản Zig, rất có thể cũng đã đạt được mức tăng hiệu năng 5%
    • Tôi hy vọng Zig không đáp trả bài blog này theo hướng thù địch. Tuy vậy, trong tương lai của Zig, có vẻ nhiều vấn đề kiểu này có thể được khắc phục hoặc dịch chuyển nhờ công cụ tốt hơn và các kiểm tra của compiler
      Từ khá lâu đã có nhiều ý kiến rằng Rust và LLM là một cặp kết hợp ăn ý. Nhiều ma sát của ngôn ngữ được làm mượt đi nhờ lập trình có LLM hỗ trợ
    • Tôi nghĩ những người muốn dùng Zig hiểu rằng các thứ đó là vấn đề ở cấp dự án, chứ không phải vấn đề ở cấp ngôn ngữ
    • Đúng, nhưng bản thân việc viết lại thường mang lại những lợi ích như vậy. Kể cả nếu viết lại bằng Zig thì có khả năng một phần các cải thiện tương tự cũng sẽ xuất hiện
    • Tôi chú ý đến những người đưa ra quyết định khó khăn thông qua các bài học cay đắng. Đại loại như đa số người dùng ORM chọn nó chỉ vì từng nghe đến hoặc không muốn học SQL, còn người loại bỏ ORM thường là người đã trực tiếp trải qua nỗi kinh hoàng

  • Tôi không bận tâm chuyện họ dùng AI để viết lại Bun bằng Rust. Ngay cả nếu 1.4 chưa đủ tốt thì theo thời gian có khả năng nó sẽ khá hơn
    Điều đẩy tôi quay lại Node là quá trình chuyển đổi được xử lý quá nghiệp dư
    Phiên bản Zig không có hỗ trợ LTS cho CVE và những thứ tương tự; các lỗi lớn như rò rỉ bộ nhớ 3MB nêu trong bài blog bị bỏ mặc trong phiên bản Zig, về thực chất buộc ai muốn sửa ứng dụng production phải chuyển sang phiên bản Rust; và không hề có sự tham gia nào với cộng đồng Bun về quyết định hệ trọng như vậy
    Một hôm thì là “đừng tạo drama, chỉ đang nghịch thôi”, vài ngày sau đã thành “YOLO, merge vào main”
    Jarred về cơ bản vẫn vận hành như một hacker đơn độc làm dự án cá nhân của mình

    • Việc phiên bản Zig không có hỗ trợ LTS cho CVE, v.v. nghĩa là mỗi bản phát hành sẽ có đầy CVE và sẽ tốn công sức khổng lồ
      Chẳng hạn như ví dụ về vấn đề bộ nhớ trong blog. Về mặt bảo mật, tốt hơn nên coi như phiên bản Zig chưa từng tồn tại. Dùng thì tự chịu trách nhiệm
      Còn việc Jarred vận hành như dự án cá nhân thì dù sao họ cũng có quyền làm vậy. Đặc biệt nếu đó là công ty sở hữu thì cũng là điều có thể dự đoán
    • Khách hàng trả phí nhận được LTS. Có khách hàng trả phí nào yêu cầu LTS cho nhánh Zig không? Hay là đang kỳ vọng maintainer mã nguồn mở làm lao động miễn phí mà không có lý do đặc biệt?
    • Nếu 1.4 không tạo thay đổi phá vỡ từ 1.3, thì vì sao những người ở lại 1.3 cần có LTS và bảo đảm? Theo tôi thấy, mọi regression đã biết đều đã được sửa như các bản phát hành khác
    • LTS liên quan hơn khi tính tương thích bị phá vỡ. 1.4 thậm chí còn chưa được phát hành, và theo mọi chỉ số thực tế thì mọi thứ có vẻ diễn ra rất tốt. Rất nhiều người đã dùng nó với Claude Code suốt một tháng mà không có regression
      Tôi không thấy điểm nào có thể gọi là cẩu thả
      Ngược lại, anh ấy còn gắn hai instance Claude đóng vai người review đối kháng vào mọi thay đổi code, từng dòng một. Ngoài những người từng viết phần mềm tàu con thoi ra, tôi không biết đội ngũ con người nào thực hiện hai lần review độc lập cho từng dòng như vậy
      Rò rỉ bộ nhớ cũng đã được sửa. Việc nó được viết bằng ngôn ngữ nào có quan trọng gì? Rốt cuộc người ta chạy code TypeScript, v.v. bằng Bun
      Người dùng Bun quan tâm đến việc Bun được viết bằng Zig đến mức nào? Tôi thì hoàn toàn không. Tôi đã dùng Bun 2 năm và chỉ tra Zig khoảng một lần. Đơn giản là không liên quan
      Nó ổn định hơn chưa? Rồi. Nhỏ hơn chưa? Rồi. Nhanh hơn chưa? Rồi. Có bằng chứng nào cho thấy nó kém an toàn hơn không? Không. Code đã được công khai trong hai tháng, và đến giờ những người phản đối lẽ ra phải tìm ra bằng chứng quyết định rồi, nhưng họ không tìm được
      Cần thêm bao nhiêu bằng chứng nữa để thấy đây là một thành công lớn?
      Đây là thực tế mới. Agent đã đủ tốt để bước vào vùng có thể thực hiện những dự án như thế này, và điều đó thật thú vị

  • “Việc viết lại bằng Rust này vốn là chuyện sẽ mất 1 năm với một đội kỹ sư nắm được toàn bộ ngữ cảnh của codebase. Bằng Fable và 1 kỹ sư giám sát Claude Code sát sao, từ lúc bắt đầu đến khi bộ test pass 100% trên mọi nền tảng chỉ mất 11 ngày”
    Về mặt kỹ thuật thì rất ấn tượng, nhưng họ hơi lướt qua việc nếu Bun không phải là một phần của Anthropic thì chi phí token sẽ là 165.000 đô la
    So sánh này không hoàn toàn công bằng. Nếu tính chi phí bổ sung là 0 đô la thì nghĩa là một nhóm nhỏ sẽ mất 1 năm để port
    Tôi muốn so sánh giữa việc chi 165.000 đô la cho Claude trong 11 ngày với việc chia số tiền đó cho 50 người để viết lại mã Zig theo từng dòng. Có vẻ Claude sẽ nhanh hơn và vì thế rẻ hơn, nhưng chênh lệch có thể không quá lớn

    • Tính nhẩm thì khá dễ. Một người làm khoảng 250 ngày mỗi năm, và nếu giả định mức lương Bay Area thì ngay cả theo cách tính thận trọng, tổng chi phí đầy đủ cũng khoảng 300.000 đô la mỗi năm
      Tức là 1.200 đô la mỗi ngày
      50 người * 11 ngày là 660.000 đô la, gấp 4 lần chi phí Claude
      Hơn nữa còn đang giả định 50 người đó làm việc mà không bị kẹt, không giẫm chân nhau, không gặp vấn đề điều phối. Chỉ riêng độ phức tạp điều phối đã khổng lồ rồi
      Tôi không thích kết luận này, nhưng ở đây Claude thắng dễ. Không phải chỉ nhỉnh hơn chút ít
    • Chỉ riêng việc điều phối 50 người một cách có ý nghĩa có lẽ cũng mất ít nhất 11 ngày
    • Có vẻ khác biệt cốt lõi là người triển khai bằng AI có thể trở nên rẻ hơn, nhanh hơn, và trên thực tế là tốt hơn một cách đồng đều, trong khi để cùng những con người đó đạt được như vậy là rất khó
      Dù chưa phải câu trả lời của hôm nay, ít nhất cũng có thể xem đây là tín hiệu cho một tương lai khả dĩ chứ?
    • Ví dụ dùng 50 người cho việc này làm tôi nhớ đến câu kinh điển “chín phụ nữ không thể sinh một em bé trong một tháng”
      Gợi ý: 50 người đó cần được điều phối
    • Jarred đã dùng model cấp Mythos, nhưng nếu một số model open-weight có năng lực tương đương, đặc biệt GLM 5.2 nhìn bề ngoài có vẻ như vậy, thì sẽ rẻ hơn chuyên gia rất, rất nhiều
      Ước tính chi phí lần lượt khoảng DeepSeek v4 Pro & Mimo v2.5 Pro 3.426 đô la, Tencent HY3 3.892 đô la, GLM 5.2 30.016 đô la, Qwen 3.7 Max 37.925 đô la, Claude Opus 4.8 & GPT 5.5 xhigh 82.750 đô la
      Dựa trên 5,9 tỷ token đầu vào không được cache, 690 triệu token đầu ra, và 72 tỷ lượt đọc token đầu vào đã cache

  • Đây chính là sức mạnh của một bộ test mạnh. LLM rất giỏi khi có phần thưởng có thể kiểm chứng
    Tôi nghĩ sắp tới sẽ có nhiều dự án được viết lại bằng Rust hơn rất nhiều. Rust cũng là mục tiêu lý tưởng cho kiểu viết lại này vì nó cung cấp nhiều kiểm chứng thông qua hệ thống kiểu, đồng thời có overhead thấp mà không cần garbage collection
    Trong thời đại agent coding, lý do để dùng ngôn ngữ có garbage collection ngày càng ít đi
    Tôi xem Rust là mục tiêu tối ưu cục bộ cho việc coding bằng LLM. Tương lai có thể sẽ xuất hiện ngôn ngữ tốt hơn, nhưng có lẽ Rust sẽ thống trị trong một thời gian khá dài

    • Cũng có thể là vì vòng lặp phát triển nhanh hơn. Các bảo đảm an toàn của Rust không miễn phí, và dù vẫn rất tuyệt, chúng ảnh hưởng đến thời gian lặp
      Tôi từng chuyển một dự án cá nhân hơn 300.000 dòng từ Python sang TypeScript, và lý do chắc chắn khiến tôi không dùng Rust là thời gian lặp khi phát triển

  • Tôi tò mò Anthropic dùng Bun theo cách nào. Tôi biết nó được dùng làm “runtime” của Claude Code, nhưng thay vì chuyển 1 triệu dòng Zig sang Rust, chẳng lẽ không thể port Claude Code sang Rust để khỏi phải bundle cả JS runtime sao?
    Anthropic còn dùng Bun cho việc gì khác không? Có thể là để gọi công cụ chạy JS trong phản hồi của Claude chẳng hạn

    • Tôi cũng thắc mắc điều tương tự. Đặc biệt vì Codex được viết bằng Rust nên càng vậy
      Sao họ không chỉ chuyển Claude Code đi nhỉ
      Tôi đoán có thể bộ test của nó không đủ vững chắc
      Việc lần này có thể sẽ khiến họ mạnh dạn hơn

  • Quan điểm “về mặt lịch sử, viết lại là một ý tưởng tệ hại” đã thay đổi trong 5 năm qua
    Trường hợp đầu tiên là khi tôi gia nhập một công ty có một sản phẩm phần mềm gần như không hoạt động. Chúng tôi đã refactor và viết lại theo kiểu tăng dần truyền thống, nhưng cuối cùng học được rằng phần lõi đã mục ruỗng đến mức viết lại từ các nguyên lý đầu tiên là cách tốt nhất
    Bài học rút ra là quan niệm thông thường có lẽ chỉ áp dụng khi viết lại những hệ thống phức tạp nhưng vẫn hoạt động
    Sau đó, trong thời đại agent coding, tôi đã trải qua nhiều tình huống khác nhau. Xen giữa công việc chính và sở thích cá nhân, tôi đã tái tạo những mảng lớn của các phần mềm phức tạp như Salesforce, Gmail, Pioneer Rekordbox bằng các nhóm rất nhỏ
    Cũng như bài blog, điểm mấu chốt là tạo ra các vòng lặp kiểm chứng xuất sắc quanh hành vi cốt lõi bằng compiler, linter, test harness và bộ test
    Càng ngày tôi càng cảm thấy việc thiết kế và triển khai test harness tổng hợp hơn mới là công việc thật sự. Một khi đã có nó, cứ để LLM nấu nướng

    • Tôi cũng nghĩ tương tự. Công việc của chúng ta có thể chuyển thành người chăn các coding agent
      Trong trường hợp này, những thứ như test harness, linter, workflow có lẽ sẽ là chó chăn cừu của chúng ta

  • Điều thú vị là phần lớn các cuộc thảo luận xoay quanh chủ đề này đều diễn ra trên giả định rằng việc viết lại được thực hiện bằng một mô hình như Opus chứ không phải Fable
    Giả định đó, ít nhất một phần, đã được dùng làm luận cứ rằng việc viết lại là không khả thi hoặc không phải là ý tưởng hay
    Bản thân mô hình không hoàn toàn thay đổi câu chuyện, nhưng cá nhân tôi cảm thấy mình cần thận trọng hơn khi ước đoán năng lực của các mô hình mà Anthropic và các tổ chức liên quan sử dụng nội bộ

    • Tôi cũng nghĩ như vậy. Nhìn lại thì rất có thể tôi đã hiểu nhầm khi hồi tháng 5 Jarred mô tả mẫu “viết lại tất cả file .zig thành .rs”, nói như thể đó là việc tôi có thể làm theo mẫu đó vào tháng 5
      Điều không được nói ra là anh ấy đang dùng Fable trước khi ra mắt. [1]
      Một tín hiệu cho lần sau có thể là khi một công ty thuộc sở hữu của Anthropic tắt trailer Claude Co-Authored-By. [2] Nếu là năm có IPO thì họ lẽ ra phải tận dụng mọi cơ hội để quảng bá Claude, ngoại trừ trường hợp đó là thứ như Fable vào tháng 5, khi chưa được phép công bố
      [1]: https://xcancel.com/jarredsumner/status/2060050586024743376#...
      [2]: https://github.com/oven-sh/bun/commit/23427dbc12fdcff30c23a9...

  • Mỗi lần viết lại một dự án lớn, họ đều làm cho nó nhỏ hơn và nhanh hơn, đồng thời sửa tất cả lỗi lớn và cả phần lớn lỗi nhỏ
    Đội ngũ hiện tại cũng có trải nghiệm tương tự. Tôi tò mò nếu viết lại từ Zig sang Zig với cùng quy mô thì sẽ ảnh hưởng thế nào đến chất lượng
 
GN⁺ 5 ngày trước
Các ý kiến trên Lobste.rs
  • Ngay cả nếu dùng C++ thì có lẽ đó cũng là một lựa chọn hợp lý cho Bun. Họ có thể có constructor và destructor, đồng thời xóa được rất nhiều mã wrapper extern "C", nhưng vẫn sẽ phải dựa vào style guide được ép buộc qua code review, và dù có ASAN thì hỏng bộ nhớ và rò rỉ bộ nhớ vẫn sẽ tiếp diễn
    Thú vị là Node.js vẫn chạy tốt với C++, nhưng tôi chưa bao giờ xem Bun là một dự án nghiêm túc. Giờ nó trông như một test bench của bộ phận marketing Anthropic, nên tôi vẫn sẽ tránh xa
    • Node chắc chắn cũng từng có các CVE về an toàn bộ nhớ xuất phát từ mã thư viện của chính nó. Chỉ cần tìm "nodejs memory cves" là thấy ngay vài trường hợp
    • Nói Node chạy tốt với C++ cũng cùng mức với nói Bun đã chạy tốt với Zig. Node được chú ý và có nhiều người dùng hơn nên vấn đề lộ ra nhanh hơn, còn rốt cuộc cả hai đều ở trong tình huống “nếu cực kỳ cẩn thận và không ai mắc lỗi thì sẽ hoạt động hoàn hảo”
      Spoiler: thực tế thì người ta không cẩn thận đến thế, và vẫn mắc lỗi
  • Câu “khoảng 4% mã Rust của Bun nằm trong các khối unsafe, và 78% trong số đó chỉ là một dòng” nghe như muốn trấn an, nhưng việc một khối unsafe có một dòng hay không không quan trọng. Nếu trong đó phá vỡ các bảo đảm an toàn, thì toàn bộ mã bên ngoài khối cũng có khả năng bị phá vỡ soundness
    Bản merge ban đầu của port Rust cho Bun có chứa dạng unsoundness rõ ràng như thế này: https://github.com/oven-sh/bun/issues/30719
    Vấn đề đó đã được các maintainer phản hồi bằng cách bật công cụ Miri của Rust trong CI, và phần “What's Next” của bài viết cũng có Miri (which runs for a growing chunk of code in CI), nên có vẻ họ đang làm theo hướng đó, điều này là tốt
    Công bằng mà nói, ngay cả Rust có vi phạm an toàn cũng có thể dễ bảo trì hơn tùy vào chất lượng của mã Zig mà nó thay thế. Dù vậy, số dòng mã trên mỗi khối unsafe không phải là thước đo chất lượng, đặc biệt nếu các khối đó cũng không đi kèm thực hành lập trình, chuyên môn hay kiểm tra tự động khác
    • Câu đó có vẻ không nhằm trấn an, mà gần với ý rằng các khối unsafe không phát sinh từ quá trình port, mà xuất phát từ yêu cầu của dự án. Nếu gọi thư viện C thì cần khối unsafe, và không có cách nào loại bỏ chỉ bằng refactoring
      Tất nhiên nếu viết lại cả thư viện C đó thì có thể, nhưng chuyện đó có thể xem xét sau
  • Một trong những điểm thú vị nhất ở Bun là về cơ bản đây là câu chuyện một kỹ sư làm được nhiều việc hơn dự kiến rất nhiều. Ban đầu Jarred nói là nhờ Zig, lần này nói là nhờ Claude, nhưng cũng không lạ nếu đó là nhờ chính Jarred hoặc đạo đức làm việc của anh ấy. Cũng có thể là sức mạnh của một nhóm nhỏ, hoặc vì họ đang viết lại và triển khai những thứ vốn đã tồn tại
    Trong thông báo “Bun is joining Anthropic”, Jarred nói họ sẽ tuyển thêm kỹ sư để làm Bun, nhưng nhìn trên GitHub thì đội Bun có vẻ lại còn nhỏ đi. Tôi không rõ rút ra kết luận gì từ đây, chỉ là “Bun là một nhóm nhỏ” mà thôi
  • Nói “viết lại là một ý tưởng tồi tệ” rồi ngay sau đó lại tiến hành viết lại
    Bản thân phương pháp thì thú vị, nhưng bài viết đọc như một bài marketing. Nó cũng thiếu phân tích về chi phí, không nói đến rủi ro đi kèm việc viết lại bằng Rust, và ngay từ đầu cũng giải thích khá mơ hồ vì sao việc viết lại xảy ra. Nếu đoán thì có thể là do chính sách không AI của Zig, hoặc do nội bộ Anthropic có định hướng tập trung vào Rust
    • Về chi phí, đoạn này ít nhất có vẻ liên quan: “trước khi merge, đã dùng 5,9 tỷ token đầu vào không cache, 690 triệu token đầu ra, và 72 tỷ lượt đọc token đầu vào đã cache; theo giá API thì khoảng 165.000 USD”
      Còn về lý do viết lại, tôi thấy bài viết kể một câu chuyện khá nhất quán. Bun vẫn tiếp tục crash dù đã có các biện pháp để bắt lỗi, và các developer muốn một cách có hệ thống hơn để ngăn các vấn đề như vậy
      Kế hoạch ban đầu là ép một số phong cách lập trình chặt chẽ hơn và đưa smart pointer vào, nhưng Jared cho rằng smart pointer tự làm có usability kém hơn Rust và cũng không có bảo đảm. Vì vậy nó trở thành “hay thử trong một tuần xem model mới của Anthropic có thể viết lại Bun bằng Rust không?”, và khi tỷ lệ vượt qua test suite tăng lên, luồng diễn biến có vẻ đã chuyển từ “đáng thử” sang “sẽ merge”
      Nói cách khác, có vẻ không phải là quyết định viết lại bằng Rust ngay từ đầu, mà gần hơn với “Rust có vẻ đưa ra lời giải cho vấn đề, nhưng không làm được vì chi phí viết lại. Nhưng thử port bằng LLM thì thấy có khả năng. Vậy hãy viết lại bằng LLM”
    • “trước khi merge, đã dùng 5,9 tỷ token đầu vào không cache, 690 triệu token đầu ra, và 72 tỷ lượt đọc token đầu vào đã cache; theo giá API thì khoảng 165.000 USD”
    • Lý do viết lại có vẻ đủ chính đáng. Có nỗi lo về các vấn đề an toàn bộ nhớ liên tục và việc sửa lỗi kiểu đập chuột chũi không có hồi kết; một số kỹ sư có thể đã xử lý theo cách khác, nhưng chọn viết lại bằng Rust với LLM cũng là một lời giải cho vấn đề
    • Đúng là đọc như bài marketing. Dù có chủ ý hay không thì là vậy, nhưng thực tế chi phí gần như không thể tính được. Đặc biệt nếu các developer có quyền truy cập vào các model Anthropic trước khi phát hành. Tuy nhiên, nếu những người bình thường như chúng ta viết lại một hệ thống quy mô như vậy bằng các model Claude hiện nay thì vẫn có thể ước tính chi phí
  • Thay vì tiếp tục sửa từng lỗi như thế này, việc cần làm tốt hơn cho những người dùng đang phụ thuộc vào nó và ngăn các lỗi này tái diễn một cách có hệ thống là một lý do rất tốt. Dù vậy, nếu lý do chỉ là “Rust đang có vibe tốt” thì tôi cũng vẫn chấp nhận
    Xin chúc mừng Jarred, đội Bun và Anthropic vì đã làm được việc này