Menulis Ulang Bun dengan Rust

 (bun.com)
2 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Bun, yang dimulai dengan Zig, telah berkembang menjadi runtime yang diunduh lebih dari 22 juta kali per bulan, tetapi kombinasi mesin JavaScript berbasis GC dan manajemen memori manual memicu masalah stabilitas berulang yang menjadi alasan untuk beralih ke Rust
  • Alih-alih memindahkan 535.496 baris kode Zig secara manual selama setahun, mereka menjalankan sekitar 50 workflow dinamis Claude Code dan hingga 64 instance Claude secara paralel selama 11 hari
  • Porting diverifikasi dengan PORTING.md, LIFETIMES.tsv, 1 implementer dan setidaknya 2 reviewer adversarial, serta test suite TypeScript yang sudah ada, dan lulus 100% di CI untuk 6 platform
  • Setelah beralih ke Rust, Bun v1.4.0 memperbaiki 128 bug yang dapat direproduksi di v1.3.14, memperbaiki semua kebocoran memori yang dapat diinstrumentasi, serta mengurangi ukuran binary Linux dan Windows sekitar 20%
  • Bun v1.3.14 adalah versi Zig terakhir, sedangkan v1.4.0 adalah versi Rust pertama yang tersedia di canary; tim menggunakan borrow checker, Miri, LeakSanitizer, dan fuzzing berbasis coverage 24/7 sebagai alat untuk meningkatkan stabilitas

Bun yang Dimulai dengan Zig dan Masalah Stabilitas

  • Bun bermula sebagai proyek yang melakukan porting baris demi baris transpiler JavaScript/TypeScript esbuild dari Go ke Zig
  • Kode Zig pertama ditulis pada 16 April 2021, dan kontrol level rendah serta desain berorientasi performa milik Zig memungkinkan implementasi awal Bun
  • Bun awal ditulis dalam Zig oleh satu orang selama 1 tahun, dengan cakupan yang sangat luas
    • Transpiler, minifier, dan bundler JavaScript, TypeScript, CSS
    • Package manager yang kompatibel dengan npm
    • Test runner mirip Jest
    • Resolusi modul yang kompatibel dengan Node.js dan TypeScript
    • Klien HTTP/1.1 dan WebSocket
    • Implementasi API Node.js seperti fs, net, tls
  • Saat ini Bun CLI diunduh lebih dari 22 juta kali per bulan, digunakan sebagai runtime oleh Claude Code dan OpenCode, serta mendapat dukungan 1st-party dari Vercel, Railway, DigitalOcean, dan lainnya

Bug Stabilitas Memori yang Berulang

  • Sampel bug yang diperbaiki di Bun v1.3.14 mencakup use-after-free, double-free, kebocoran memori, akses out-of-bounds, dan race condition
    • Heap-use-after-free akibat pemanggilan .reset() saat async .write() di node:zlib
    • Use-after-free ketika callback JS reentrant di node:http2 memicu rehash hashmap sehingga pointer stream internal menjadi tidak valid
    • Masalah ketika callback valueOf() atau toString() pada UDPSocket.send() dan sendMany() melakukan detach pada ArrayBuffer
    • Crash dan out-of-bounds read akibat detach atau resize ArrayBuffer selama coercion argumen di Buffer#copy dan Buffer#fill
    • Kebocoran memori terkait crypto.scrypt, tlsSocket.setSession(), dan fs.watch()
    • Double-free saat parser CSS menangani vendor prefix dan background multi-layer
    • Crash akibat race condition MessageEvent saat akses bersamaan ke BroadcastChannel atau MessagePort
  • Sebelumnya, berbagai mekanisme juga digunakan untuk memperkuat stabilitas
    • Menambahkan patch dukungan Address Sanitizer ke compiler Zig dan menjalankan test suite ASAN pada setiap commit
    • Mendistribusikan build ReleaseSafe dengan safety check Zig untuk Windows
    • Melakukan fuzzing 24/7 pada API runtime Bun dengan Fuzzilli
    • Mengoperasikan banyak pengujian kebocoran memori end-to-end
  • Posisinya bukan bahwa Zig itu sendiri bermasalah; sumber utama masalah stabilitas adalah tuntutan untuk menangani nilai GC dan memori yang dikelola manual secara bersamaan

Alasan Memilih Rust

  • JavaScript adalah bahasa dengan GC, dan engine seperti JavaScriptCore dan V8 memiliki aturan ketat terkait penanganan exception dan GC
  • Seperti C, Zig tidak mengelola memori secara otomatis; tidak ada constructor atau destructor, dan cleanup sebagian besar harus dinyatakan secara eksplisit dengan defer di tiap call site
  • Di Bun, menangani lifetime nilai GC dan nilai yang dikelola manual dengan benar merupakan sumber besar masalah stabilitas
    • Harus memastikan di mana byte yang dialokasikan dibebaskan
    • Harus menjamin pembebasan hanya terjadi satu kali
    • Harus memeriksa penanganan exception JavaScript dengan benar
    • Harus memastikan pointer GC terlihat oleh conservative stack scanner
  • Mekanisme cleanup Zig adalah defer dan errdefer yang eksplisit; C++ menggunakan destructor dan move, sedangkan Rust menggunakan Drop
  • Kode Zig Bun yang sudah ada mencampurkan lifetime arena, reference counting, dan review yang cermat
  • Aturan ownership juga bisa dipaksakan melalui style guide dan code review, tetapi dalam kode Rust yang aman, use-after-free, double-free, dan free yang terlewat pada error path menjadi error compiler
  • Sekitar 20% kode Bun adalah C++ dan menyertakan berbagai library C/C++
    • JavaScriptCore
    • uWebSockets dan usockets
    • lshpack dan lsquic
    • BoringSSL
    • SQLite
  • C++ juga bisa menjadi pilihan, tetapi tetap bergantung pada style guide dan code review, dan bahkan dengan ASAN, kerusakan memori serta kebocoran masih bisa terjadi

Strategi Penulisan Ulang: Sekaligus, Secara Mekanis

  • Kode Zig Bun yang ada berjumlah 535.496 baris tanpa komentar, dan penulisan ulang tradisional diperkirakan membutuhkan sekitar 1 tahun untuk tim engineer kecil
  • Karena perbaikan bug, perbaikan keamanan, dan pengembangan fitur tidak bisa dihentikan selama 1 tahun, porting mekanis yang meminimalkan perubahan perilaku bagi pengguna dipilih sebagai pendekatan dengan risiko paling rendah
  • Test suite Bun ditulis dalam TypeScript sehingga tidak bergantung pada bahasa implementasi runtime
  • Penulisan ulang inkremental dinilai menyakitkan dalam jangka pendek dan menengah karena harus membuat kode sementara lalu berharap kode itu dihapus nanti, sehingga semuanya dipindahkan sekaligus
  • Kode Rust ditulis agar terlihat seperti hasil transpile dari kode Zig, lalu setelah Bun v1.4 mereka memilih arah untuk secara bertahap mengurangi unsafe dan melakukan refactoring menjadi Rust yang idiomatic

Workflow Dinamis Claude Code

  • Dalam penulisan ulang Rust, sekitar 50 workflow dinamis di Claude Code terus berjalan selama 11 hari
  • Workflow mencakup pembuatan panduan porting, konversi file, perbaikan error kompilasi, pemulihan subcommand, pelolosan seluruh test, hingga cleanup skala besar
    • Membuat panduan porting yang memetakan pola dan tipe Zig ke pola dan tipe Rust
    • Melakukan porting mekanis semua file .zig menjadi file .rs sesuai PORTING.md dan LIFETIMES.tsv
    • Memperbaiki error compiler per crate
    • Memulihkan perilaku subcommand seperti bun test dan bun build
    • Meloloskan seluruh test suite
    • Refactoring dan cleanup skala besar
  • Sepanjang sebagian besar periode, manusia membaca output workflow, memeriksa masalah dan bug, lalu menyesuaikan prompt agar Claude memperbaiki loop tersebut
  • Sebagai pekerjaan awal, mereka berdiskusi dengan Claude selama sekitar 3 jam tentang cara memetakan pola codebase Zig ke Rust, dan hasilnya diserialisasi menjadi PORTING.md
  • Untuk menambahkan lifetime Rust ke kode manajemen memori manual, workflow dijalankan untuk menganalisis lifetime semua field struct
    • Menemukan field dengan lifetime kompleks
    • Mengusulkan lifetime
    • Ditinjau oleh 2 agen reviewer adversarial
    • Menyimpan hasilnya ke LIFETIMES.tsv setelah memasukkan feedback

Metode review adversarial

  • Untuk setiap Claude implementer, ditempatkan Claude reviewer adversarial di context window terpisah; reviewer hanya menerima diff dan diinstruksikan untuk berasumsi bahwa kodenya salah lalu mencari bug
  • Struktur dasarnya terdiri dari 1 implementer, 2 atau lebih reviewer adversarial, dan 1 fixer
  • Semua bug yang benar-benar ditemukan reviewer lolos kompilasi, tetapi bermasalah dalam perilaku
    • Karena uv_close bersifat asinkron, Box<uv::Pipe> di-drop di akhir match arm, sehingga libuv memegang freed memory yang menyebabkan use-after-free dan double-free
    • Kesalahan timespec ketika penggunaan trunc() pada file time negatif non-integer menghasilkan nsec negatif
    • Kesalahan ketika unwrap_or mengevaluasi argumennya secara eager sehingga terjadi panic pada kasus persentase color-mix() yang dihilangkan
  • Seperti review oleh manusia, context penulis dan reviewer dipisahkan untuk mengurangi bias yang bisa muncul karena implementer ingin merge

Eksekusi porting skala besar dan paralelisasi

  • Sebelum memindahkan seluruh 1.448 file .zig, prosedurnya divalidasi terlebih dahulu dengan 3 file
    • 1 implementer menulis file .rs
    • 2 reviewer memeriksa apakah perilakunya sesuai dengan .zig dan mengikuti PORTING.md, LIFETIMES.tsv
    • 1 fixer menerapkan saran
  • Pada tahap awal porting seluruh file, beberapa Claude menjalankan git stash, git stash pop, git reset HEAD --hard dan saling berkonflik
  • Setelah itu, aturan ditambahkan ke workflow untuk melarang git stash, git reset, perintah git yang bukan commit file tertentu, serta perintah lambat seperti cargo
  • Pada akhirnya digunakan 4 workflow shard dan 4 worktree, dan di setiap shard 16 Claude melakukan commit dan push file
  • Berkat paralelisasi dan persiapan sebelumnya, pada puncaknya Claude menulis sekitar 1.300 baris kode per menit
  • Commit di branch port, tidak termasuk merge, berjumlah 6.502, peak hour mencapai 695 commit, dan diff akhir yang landed adalah +1.009.272 baris
  • Ada juga masalah karena IOPS default instans EC2 tidak dinaikkan, sehingga satu grep yang lambat membuat baca-tulis disk berhenti selama beberapa menit

Error kompilasi dan pemisahan crate

  • Setelah semua kode ditulis, workflow Claude memperbaiki error compiler
  • Codebase Zig pada dasarnya merupakan satu compilation unit, sementara kode Rust hendak dibagi menjadi sekitar 100 crate demi kompilasi yang lebih cepat
  • Kategori error yang paling sulit adalah dependensi siklik
    • PR pemisahan crate tepat sebelum penulisan ulang Rust saja tidak cukup
    • Workflow terpisah mengklasifikasikan dan mencatat di mana kode dengan dependensi siklik harus ditempatkan
    • Workflow lain melakukan refactoring tersebut
  • Setelah dependensi siklik diselesaikan, sekitar 16.000 error compiler terungkap
  • Error-error ini diproses paralel per crate
    • Menjalankan cargo check di setiap crate
    • Mengelompokkan output per file dan menyimpannya
    • Memperbaiki error kompilasi pada crate tersebut
    • 2 reviewer adversarial meninjau perubahan
    • 1 fixer menerapkan perbaikan
  • Ada juga false start ketika Claude menafsirkan “mari buat semua crate bisa dikompilasi” sebagai pembuatan function stub
  • Ketika muncul pola membenarkan workaround dengan komentar penjelasan panjang, ditambahkan aturan review: “jika butuh komentar sepanjang paragraf, kodenya salah dan kodenya harus diperbaiki”

Proses hingga pengujian lulus

  • Setelah cargo check lulus, mereka menyelesaikan secara berurutan error linking, panic tepat setelah startup, eksekusi bun --version, dan bun test <file>
  • Digunakan workflow yang menyimpan stacktrace kegagalan per CLI subcommand ke file, lalu memperbaikinya melalui loop implementer-reviewer-fixer
  • Workflow file pengujian melakukan shard terhadap sekitar 100 file uji acak ke 4 worktree, menyimpan stacktrace dan error per kegagalan, lalu memperbaikinya
  • Test suite memiliki tes kebocoran memori dan integration test yang bisa timeout pada debug build
    • Tes yang menjalankan next dev dan memeriksa hot module reloading mendeteksi 100 perubahan
    • Stress test yang menghabiskan jumlah maksimum TCP socket
    • Tes baca-tulis disk dalam skala gigabyte
    • Tes yang men-spawn sekitar 10 ribu proses
  • Untuk isolasi, penggunaan memori dan CPU dibatasi dengan systemd-run dan cgroups, serta pid namespace dipisahkan
  • Meski begitu, mesin beberapa kali crash karena kehabisan ruang disk
  • Dua hari setelah CI pertama dijalankan, file pengujian yang gagal turun dari 972 menjadi 23, dan satu setengah hari setelah itu Linux sepenuhnya green
  • Pada akhirnya seluruh pengujian CI di 6 platform lulus
    • macOS x64
    • macOS arm64
    • Linux x64
    • Linux arm64
    • Windows x64
    • Windows arm64
  • Setelah 100% pengujian lulus, manusia memeriksa secara manual bahwa pengujian benar-benar dijalankan dan tidak di-skip, lalu melakukan merge
  • Saat di-merge ke main, itu bukan versioned release; belum cukup yakin untuk merilis, tetapi sudah cukup yakin untuk berkomitmen pada rewrite tersebut

Skala dan biaya pengujian

  • Selama 11 hari, dari 3 Mei hingga merge pada 14 Mei, dibuat 6.778 commit
  • Tes tidak dihapus ataupun di-skip
  • Skala pengujian per platform adalah sebagai berikut
    • Debian 13 x64: expect() 1.386.826 kali, 60.624 tes, 4.174 file
    • macOS 14 arm64: expect() 1.259.953 kali, 58.850 tes, 4.175 file
    • Windows 2019 x64: expect() 1.007.544 kali, 57.337 tes, 4.173 file
  • Pekerjaan pre-merge menggunakan 5,9 miliar uncached input token, 690 juta output token, dan 72 miliar cached input token read
  • Berdasarkan harga API, biayanya sekitar 165 ribu dolar AS
  • Diperkirakan jika dikerjakan langsung oleh manusia, 3 engineer yang memahami seluruh context codebase akan membutuhkan sekitar 1 tahun
  • Model yang digunakan adalah pre-release Claude Fable 5, dan terdapat disclosure bahwa Bun diakuisisi oleh Anthropic pada Desember 2025

Review keamanan, fuzzing, dan status unsafe

  • Setelah merge port Rust, mereka menyelesaikan 11 ronde review keamanan dengan Claude Code Security dan menangani findings-nya
  • Fuzzing berbasis coverage 24/7 ditambahkan untuk semua parser Bun
    • JavaScript
    • TypeScript
    • JSX
    • CSS
    • JSON5
    • JSONC
    • TOML
    • YAML
    • Markdown
    • INI
    • Bun Shell scripts
    • semver ranges
    • File .patch
    • CSS colors
  • Fuzzer mengirim bug yang ditemukan ke Claude agar mengajukan PR yang mencakup reproduksi dan perbaikan, sementara manusia meninjau PR tersebut
  • Hingga saat ini parser telah dijalankan 100 miliar kali dan menghasilkan sekitar 15 PR
  • Pada saat penulisan, sekitar 4% kode Rust berada di dalam block unsafe
    • Sekitar 13.000 keyword unsafe
    • Sekitar 27.000 baris / dari total sekitar 780.000 baris
    • 78% block unsafe hanya satu baris, berupa pointer dari C++ atau pemanggilan library C
  • Karena library C/C++ seperti JavaScriptCore masih terus digunakan, mereka menyatakan bahwa jumlah unsafe akan selalu lebih banyak dibandingkan proyek Rust murni

Regresi yang ditemukan setelah migrasi ke Rust

  • Penulisan ulang dengan Rust adalah perubahan berskala besar sehingga menimbulkan 19 regresi yang diketahui, dan semuanya telah diperbaiki
  • Sebagian besar berasal dari kode yang sintaksnya mirip di kedua bahasa, tetapi maknanya berbeda

  • Efek samping di dalam debug_assert!

    • assert di Zig adalah fungsi, sehingga argumennya dijalankan di semua build
    • debug_assert! di Rust adalah macro, sehingga pada release build seluruh ekspresi dihapus
    • Pemanggilan insert_stale menghilang pada release build, sehingga kasus HMR tertentu pada proyek HTML route yang menggunakan React menjadi rusak
    • Isu terkait: #30678

  • Slice dengan panjang ganjil

    • Helper Zig Bun reinterpretSlice(u16, bytes) menggunakan @divTrunc, sehingga mengabaikan trailing odd byte
    • bytemuck::cast_slice di Rust akan panic pada panjang ganjil
    • Ada regresi ketika Blob.text() dengan byte ganjil setelah UTF-16 BOM membuat process panic alih-alih mengembalikan string
    • Perbaikannya adalah kembali mengabaikan odd byte dengan &buf[..buf.len() & !1]
    • Isu terkait: #31188

  • Bounds checks

    • Kode Zig di macOS dan Linux dikompilasi dengan ReleaseFast, sehingga bounds check dihapus, sedangkan Rust release build tetap mempertahankan bounds check
    • Ukuran overflow block pada Bun module resolver masih berupa placeholder 64, sehingga ceiling turun dari 8,4 juta interned filenames menjadi 270.272
    • ptrs[4095] off-by-one yang dipindahkan menjadi dapat dicapai di proyek nyata, dan Rust melakukan panic alih-alih out-of-bounds write
    • Isu terkait: #31503

  • Format string comptime

    • Pada Output.pretty di Zig, fmt adalah comptime, sehingga marker warna <r>, <d> diubah menjadi ANSI escape sebelum substitusi argumen
    • Fungsi Rust tidak memiliki parameter comptime, sehingga marker diproses pada string yang sudah jadi, dan argumen ikut di-rewrite secara keliru
    • Di bun update -i, terminasi OSC 8 hyperlink bertabrakan dengan marker trailing <r>, sehingga r tercetak sebagai teks
    • Di Rust diperlukan macro bun_core::pretty!("<r>{}<r>", hyperlink)
    • Isu terkait: #30693

Bug dan kebocoran memori yang diperbaiki

  • Bun v1.4.0 memperbaiki 128 bug yang dapat direproduksi di v1.3.14
  • Cakupannya mencakup kebocoran memori, crash, hingga help text yang diberi warna secara keliru
  • Drop di Rust secara otomatis memanggil fungsi drop saat sebuah nilai keluar dari scope
  • Di Zig, defer harus ditambahkan di setiap call site, sehingga cleanup mudah terlewat atau terjadi cleanup ganda
  • Drop di Rust adalah pilihan yang mengurangi footgun umum, dengan menerima adanya hidden control flow
  • Drop memperbaiki beberapa kebocoran memori terkait file path dalam error handling code
  • Integrasi LeakSanitizer Bun ditingkatkan sehingga melacak semua native code memory allocations
  • Semua memory leak yang dapat diinstrumentasi telah diperbaiki

  • Peningkatan kebocoran pada Bun.build()

    • Pada Bun v1.3.14 sebelumnya, setiap pemanggilan Bun.build() in-process membuat parsed source text dan AST symbol table hidup lebih lama daripada umur build, sehingga membocorkan beberapa MB setiap kali
    • Dalam pengujian yang melakukan bundle proyek 60-module yang sama sebanyak 2.000 kali dalam satu process, v1.3.14 terus membocorkan sekitar 3MB per build
    • Di Bun v1.4.0, penggunaan memori menjadi datar
    • | 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 |

Ukuran biner, penggunaan stack, dan performa

  • Ukuran biner berkurang hanya dengan perubahan awal penulisan ulang Rust
    • Windows: turun 3,8 MB
    • macOS: turun 5,5 MB
    • Linux: turun 6,8 MB
  • Penyebab utamanya adalah penggunaan comptime yang terlalu banyak di kode Zig
  • Setelah itu, identical code folding, penghapusan unused data dari ICU, dan cara mendekompresi sebagian libicu secara lazy dengan zstd dictionary juga diterapkan
  • Jika penulisan ulang Rust, perubahan ICU, dan identical code folding digabungkan, ukuran biner Bun di Linux dan Windows berkurang sekitar 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 dan recursive-descent parser Bun kini menggunakan lebih sedikit stack space
  • Codegen LLVM IR Rust mengeluarkan intrinsic llvm.lifetime.start dan llvm.lifetime.end pada stack variable, sehingga LLVM dapat menggunakan ulang stack slot
  • Sebelumnya, untuk menghindari open issue di Zig, khususnya fungsi besar harus di-refactor secara manual menjadi beberapa fungsi kecil
  • Rust mendukung cross-language link-time optimization antara C/C++ dan Rust, sehingga inlining antarbahasa dimungkinkan

  • Benchmark Linux x64

    • Bun v1.3.14 dan Bun v1.4.0 dibandingkan di Linux x64 EC2 Xeon Platinum 8488C
    • HTTP throughput diukur dengan oha, sedangkan app workload diukur dengan 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% |

Kasus penggunaan nyata dan status rilis

  • Prisma merilis public beta Prisma Compute di atas Rust rewrite Bun
  • Pihak Prisma menyatakan bahwa mereka menguji mode kegagalan berupa connection pool yang tidak pulih setelah VM pause/resume serta memory leak pada Rust rewrite, dan rewrite tersebut menangani mode kegagalan itu dengan baik
  • Claude Code v2.1.181, serta versi setelah rilis 17 Juni, menggunakan Bun port Rust
  • Startup Claude Code di Linux menjadi 10% lebih cepat, sementara hal lain hampir tidak disadari oleh sebagian besar pengguna
  • Bun v1.3.14 adalah versi Bun terakhir yang ditulis dengan Zig
  • Bun v1.4.0 adalah versi Bun pertama yang ditulis dengan Rust dan tersedia sebagai canary

Alat yang diperoleh tim dan pekerjaan yang tersisa

  • Codebase Rust baru mempertahankan bentuk yang sangat mirip dengan codebase Zig yang ada
  • Kode Rust yang diterjemahkan secara mekanis ditulis agar orang yang memahami kode Zig asli juga dapat memahaminya
  • Review PR Rust rewrite dilakukan dengan memastikan agent review adversarial benar-benar menangkap ketidaksesuaian antara Zig dan Rust, serta kepatuhan terhadap panduan porting dan lifetime guide, lalu manusia membaca banyak kode secara side-by-side
  • Bun v1.4 membuat Bun lebih cepat dan lebih kecil, mengurangi penggunaan memori, serta menyediakan alat untuk peningkatan stabilitas
    • Rust borrow checker
    • Miri
    • LeakSanitizer
    • coverage-guided fuzzing 24/7 untuk target parser
  • Masih ada bagian yang perlu direfaktor, dan bun-unsafe-audit telah dihubungkan
  • Seorang engineer memantau Fable dan Claude Code secara ketat, sehingga hanya dalam 11 hari mereka mencapai kondisi seluruh test suite lolos di semua platform

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Komentar di Lobste.rs
  • Menurut saya, bahkan jika memakai C++, itu tetap akan menjadi pilihan yang masuk akal untuk Bun. Mereka mungkin bisa mendapatkan constructor dan destructor serta menghapus banyak kode wrapper extern "C", tetapi tetap harus bergantung pada panduan gaya yang dipaksakan lewat code review, dan meski ada ASAN, korupsi memori dan kebocoran memori akan tetap terjadi
    Menariknya, Node.js berjalan baik dengan C++, tetapi saya tidak pernah melihat Bun sebagai proyek yang serius. Sekarang tampak seperti test bench untuk departemen pemasaran Anthropic, jadi saya berniat terus menjauhinya
    • Node juga jelas pernah punya CVE keamanan memori yang berasal dari kode library-nya sendiri. Cukup cari "nodejs memory cves" dan beberapa kasus langsung muncul
    • Mengatakan Node berjalan baik dengan C++ itu setara dengan mengatakan Bun berjalan baik dengan Zig. Node hanya punya lebih banyak perhatian dan pengguna, sehingga masalah lebih cepat terlihat; pada akhirnya keduanya berada dalam situasi “berfungsi sempurna kalau sangat hati-hati dan tidak ada yang membuat kesalahan”
      Spoiler: dalam praktiknya, orang tidak sehati-hati itu dan tetap membuat kesalahan
  • Pernyataan “sekitar 4% kode Rust Bun berada di dalam blok unsafe, dan 78% di antaranya hanya satu baris” terdengar seperti upaya menenangkan, tetapi apakah blok unsafe itu satu baris atau bukan tidaklah penting. Jika jaminan keamanan dilanggar di dalamnya, semua kode di luar blok itu juga berpotensi kehilangan soundness
    Merge awal port Rust Bun berisi unsoundness yang jelas seperti ini: https://github.com/oven-sh/bun/issues/30719
    Isu tersebut ditangani dengan para maintainer mengaktifkan tool Miri milik Rust di CI, dan bagian “What's Next” di artikel juga mencantumkan Miri (which runs for a growing chunk of code in CI), jadi bagus bahwa mereka sedang mengerjakan arah itu
    Secara adil, Rust yang memiliki pelanggaran keamanan pun bisa lebih mudah dipelihara, tergantung kualitas kode Zig yang digantikannya. Namun, jumlah baris kode per blok unsafe bukanlah metrik kualitas, apalagi jika blok-blok itu tidak disertai praktik coding lain, keahlian, maupun pemeriksaan otomatis
    • Kalimat itu tampaknya bukan untuk menenangkan, melainkan lebih bermakna bahwa blok unsafe muncul bukan karena proses porting, melainkan karena kebutuhan proyek. Jika memanggil library C, blok unsafe diperlukan, dan tidak ada cara menghilangkannya hanya dengan refactoring
      Tentu saja bisa jika library C itu juga ditulis ulang, tetapi itu mungkin dapat dipertimbangkan nanti
  • Salah satu hal paling menarik dari Bun adalah bahwa pada dasarnya ini adalah kisah tentang satu engineer yang menyelesaikan jauh lebih banyak hal daripada perkiraan. Awalnya Jarred mengatakan itu berkat Zig, dan kali ini berkat Claude, tetapi tidak aneh juga kalau itu berkat Jarred sendiri atau etos kerjanya. Bisa juga karena kekuatan tim kecil, atau karena mereka menulis ulang dan mengimplementasikan hal-hal yang sudah ada
    Dalam pengumuman “Bun is joining Anthropic”, Jarred mengatakan mereka akan merekrut lebih banyak engineer untuk mengerjakan Bun, tetapi jika hanya melihat GitHub, tim Bun justru tampak menyusut. Saya tidak tahu kesimpulan apa yang bisa diambil dari sini, selain bahwa “Bun adalah tim kecil”
  • Mereka mengatakan “rewrite adalah ide buruk”, lalu langsung melakukan rewrite
    Metodenya sendiri menarik, tetapi artikelnya terbaca seperti artikel pemasaran. Analisis tentang berapa biayanya juga kurang, risiko yang menyertai rewrite ke Rust tidak dibahas, dan penjelasan konkret tentang mengapa rewrite terjadi sejak awal juga lemah. Kalau menebak, mungkin karena no ai policy Zig, atau karena ada kebijakan internal Anthropic untuk berfokus pada Rust
    • Soal biaya, bagian ini setidaknya tampak relevan: “Sebelum merge, digunakan 5,9 miliar token input yang tidak di-cache, 690 juta token output, dan 72 miliar pembacaan token input yang di-cache; berdasarkan harga API, biayanya sekitar 165.000 dolar AS”
      Dan menurut saya artikel itu menyampaikan cerita yang cukup konsisten tentang mengapa mereka menulis ulang. Bun terus mengalami crash meski sudah mengambil langkah untuk menangkap masalah, dan para developer menginginkan cara yang lebih sistematis untuk mencegah masalah semacam itu
      Rencana awalnya adalah memaksakan gaya coding tertentu dengan lebih ketat dan memperkenalkan smart pointer, tetapi Jared menilai smart pointer buatan sendiri lebih buruk dari Rust dari sisi kegunaan dan tidak memberi jaminan. Jadi alurnya menjadi “bagaimana kalau kita menguji selama seminggu apakah model baru Anthropic bisa menulis ulang Bun ke Rust?”, lalu ketika tingkat kelulusan test suite meningkat, itu berubah dari “layak dicoba” menjadi “akan di-merge”
      Dengan kata lain, tampaknya mereka bukan sejak awal memutuskan rewrite ke Rust, melainkan lebih seperti “Rust tampaknya memberi solusi untuk masalah ini, tetapi biaya rewrite membuatnya tidak bisa dilakukan. Namun setelah mencoba porting dengan LLM, ternyata ada kemungkinan. Kalau begitu mari kita lakukan rewrite dengan LLM”
    • “Sebelum merge, digunakan 5,9 miliar token input yang tidak di-cache, 690 juta token output, dan 72 miliar pembacaan token input yang di-cache; berdasarkan harga API, biayanya sekitar 165.000 dolar AS”
    • Alasan rewrite tampak cukup sah. Ada masalah keamanan memori yang terus berlanjut dan ketakutan terhadap perbaikan bug tanpa akhir seperti permainan whack-a-mole; sebagian engineer mungkin akan menanganinya dengan cara lain, tetapi memilih rewrite Rust dengan LLM juga merupakan salah satu solusi terhadap masalah tersebut
    • Memang terasa seperti artikel pemasaran. Disengaja atau tidak, tetapi sebenarnya menghitung biayanya hampir mustahil. Terutama jika para developer punya akses ke model Anthropic sebelum rilis. Namun jika kita, orang biasa, menulis ulang skala sebesar itu dengan model Claude saat ini, biayanya bisa diperkirakan
  • Daripada terus memperbaiki bug seperti ini satu per satu, alasan bahwa mereka harus berbuat lebih baik bagi para pengguna yang bergantung pada mereka dan mencegah bug semacam ini berulang secara sistematis adalah alasan yang bagus. Meski begitu, kalau alasannya hanya “suasana Rust sedang bagus” pun saya rasa masih bisa diterima
    Selamat untuk Jarred, tim Bun, dan Anthropic karena berhasil melakukannya