- Jarred Sumner, pendiri Bun, meng-commit panduan porting Zig → Rust (PORTING.md) ke branch
claude/phase-a-port, sehingga eksperimen konversi bahasa skala besar dengan memanfaatkan agen AI pun dipublikasikan
- Porting dibagi menjadi Phase A (terjemahan kasar logika per file, tidak perlu bisa dikompilasi) dan Phase B (lolos kompilasi per crate), dengan pendekatan memberi LLM sekitar 300 aturan pemetaan tipe dan idiom
- Sumner sendiri menjelaskan di Hacker News bahwa "belum diputuskan untuk melakukan rewrite, dan kemungkinan besar semua kode ini akan dibuang", sehingga saat ini masih berada pada tahap eksplorasi eksperimental
- Di komunitas, setelah akuisisi Anthropic, yang disebut-sebut sebagai latar belakang adalah benturan dengan kebijakan Zig yang melarang kontribusi AI, fakta bahwa Bun sudah beroperasi dengan fork Zig sendiri, serta keunggulan keamanan ekosistem Rust
- Sebagian besar PR dibuat otomatis oleh @robobun (bot AI), lalu ditinjau oleh CodeRabbitAI dan Claude, sehingga ini menjadi contoh yang menunjukkan kemungkinan nyata sekaligus keterbatasan migrasi kode skala besar yang digerakkan AI
Struktur inti panduan porting (PORTING.md)
- Target porting adalah mengubah satu file Zig menjadi file
.rs di direktori yang sama; pada Phase A tujuannya adalah mereproduksi logika dengan setia dan apakah bisa dikompilasi tidak menjadi masalah
- Penggunaan crate async dan I/O eksternal dilarang seperti
tokio, rayon, hyper, async-trait, std::fs, std::net — karena Bun memiliki event loop dan syscall-nya sendiri
async fn dilarang, semua pemrosesan async dipertahankan dalam bentuk callback + state machine seperti di Zig- Bagian yang belum yakin diberi tanda
// TODO(port):, sedangkan idiom Zig yang terkait performa diberi // PERF(port): untuk ditangani pada Phase B
Aturan pemetaan tipe dan idiom
- Disediakan tabel pemetaan lebih dari sekitar 50 tipe seperti
[]const u8 → &[u8] (sama sekali bukan &str), ?T → Option<T>, anyerror!T → Result<T, bun_core::Error>
defer x.deinit() → dihapus lalu diganti dengan impl Drop, errdefer → memakai scopeguard, comptime → dikonversi ke const generic, const fn, macro_rules!- String mengikuti prinsip pemrosesan berbasis byte: penggunaan
std::string::String atau &str dilarang dan harus memakai &[u8]/Vec<u8> — karena Bun menangani WTF-8 dan byte arbitrer
@intCast → T::try_from(x).unwrap() (selalu diperiksa), @truncate → x as T (wrapping yang disengaja), @bitCast → transmute; dirapikan juga padanan Rust untuk tiap fungsi bawaan Zig
Peta crate dan model kepemilikan
- Namespace Zig seperti
@import("bun").X dipetakan 1:1 ke sekitar 30 crate Rust seperti bun_str, bun_sys, bun_jsc, bun_alloc
- Crate AST/parser tetap mempertahankan arena
bumpalo::Bump, sedangkan crate lain menggunakan allocator global mimalloc sehingga parameter allocator dihapus
- Pemetaan kepemilikan pointer seperti
bun.ptr.Owned → Box<T>, bun.ptr.Shared → Rc<T>, bun.ptr.AtomicShared → Arc<T>
Reaksi komunitas (Lobsters·HN)
- Banyak pendapat yang mempertanyakan "apakah benar ingin beralih ke Rust, atau ini sekadar showcase LLM Anthropic"
- Ada spekulasi bahwa benturan antara kebijakan Zig yang melarang kontribusi AI dan workflow pengembangan berpusat pada AI milik Anthropic bisa menjadi latar belakangnya, meski juga dinilai sendiri masih sebatas teori konspirasi
- Ada pandangan skeptis soal apakah LLM bisa mengikuti sekitar 300 aturan dengan setia — namun ada juga penilaian positif seperti "~16k token itu pas untuk sub-agent"
- Ada pengamatan menarik bahwa pendekatan lebih dulu membuat kode yang belum bisa dikompilasi pada Phase A justru kebalikan dari cara memakai coding agent yang umum
- Beban memelihara fork Zig milik Bun, breaking change yang kerap terjadi di Zig, serta risiko menggantungkan produk inti pada bahasa yang masih beta juga disebut sebagai motivasi perpindahan
2 komentar
Komentar Hacker News
Saya bekerja di Bun, dan ini branch saya
Thread ini secara keseluruhan adalah reaksi berlebihan. Ada sampai 302 komentar pada kode yang bahkan belum berjalan, tetapi belum diputuskan bahwa ini pasti akan ditulis ulang, dan ada kemungkinan besar seluruh kode ini akhirnya dibuang
Saya ingin melihat seperti apa versi yang benar-benar berjalan, bagaimana rasanya, bagaimana performanya, dan seberapa sulit membuatnya lolos kumpulan tes Bun serta tetap bisa dipelihara. Saya ingin membandingkan versi Rust dan versi Zig yang benar-benar layak secara berdampingan
Bagian soal “apakah sulit membuatnya lolos kumpulan tes Bun dan tetap bisa dipelihara” terasa menarik, karena tiap bulan muncul peluang baru untuk sepenuhnya mengabstraksikan proses porting kode lewat agen, dan semuanya berbasis linguistik
Kalau mencari contoh yang mirip dan sama menariknya, vinext dari Cloudflare yang mem-port Next.js beberapa bulan lalu layak dilihat. Awalnya ada masalah adaptasi, tetapi sekarang sudah dipakai di beberapa proyek produksi tanpa masalah besar
[0] - https://github.com/cloudflare/vinext
Rasanya wajar kalau orang bertanya kenapa pemrosesan gambar atau webview ditambahkan ke dalam runtime JavaScript sementara bug yang berdampak ke produksi masih dibiarkan. Misalnya, salah satu penghambat terbesar bagi kami adalah https://github.com/oven-sh/bun/issues/6608, yang dilaporkan pada 2023 dan masih berdampak bagi kami bahkan 3 tahun kemudian
Sebagai konteks, saat terakhir kali saya memakai Bun, saya menemukan beberapa bug di bagian seperti Bun.write yang mungkin akan terbantu jika ditulis dengan Rust
[0]: https://mastrojs.github.io/blog/2025-10-29-what-struggled-wi...)
Pada akhirnya, terlepas dari bahasa atau alatnya, pilih saja yang paling cocok untuk proyek dan situasinya. Secara pribadi eksperimen ini menarik dan saya penasaran bagaimana kelanjutannya. Untuk menulis Rust yang idiomatis dibutuhkan perubahan cara berpikir, jadi menarik juga melihat seberapa baik LLM beradaptasi dengan itu seiring waktu
Semoga kodenya elegan, dan bukan cuma bisa dipelihara, tetapi juga siap masa depan dan berkinerja baik
Menarik melihat ini ketika tulisan teratas HN saat ini membahas kekhawatiran soal Bun karena akuisisi Bun oleh Anthropic. Komentar teratas di sana nadanya seperti “Anthropic akan bereksperimen di codebase mereka sendiri, bukan berarti tim Bun akan melakukan eksperimen vibe coding seperti itu”
Tapi yang terlihat sekarang justru seperti pekerjaan besar yang dilakukan dengan vibe coding
Waktu yang akan menjawab hasilnya, tetapi akan bagus kalau maintainer Bun menjelaskan apa yang mereka lakukan di sini dan kenapa
Mungkin sedikit dari keduanya
Kalau ada codebase yang sudah ada sebagai referensi, banyak masalah dalam vibe coding jadi berkurang. Sudah ada arsitektur yang berjalan dengan baik, dan ada kumpulan tes untuk dibandingkan
Dalam sebulan saya sudah sampai ke kondisi lolos lebih dari 95% kumpulan tes Postgres dari titik awal tanpa apa-apa. Kalau Jarred adalah orang yang membangun Bun, sepertinya dia bisa melaju jauh lebih cepat
[0] https://github.com/malisper/pgrust
Baru-baru ini mereka mengusulkan sebagian tool internal mereka sebagai implementasi Rust resmi untuk Connect RPC. Itu kumpulan library berbasis Protobuf, jadi juga mencakup Buffa, compiler Protobuf baru berbasis Rust
[0]: https://github.com/orgs/connectrpc/discussions/7#discussionc...
[1]: https://connectrpc.com/
[2]: https://github.com/anthropics/buffa
Kalau Anda investor dan ingin tahu apakah waktu dipakai secara efektif, saya mengerti, tetapi selain itu saya kurang paham kenapa ini penting bagi orang lain
Menarik melihat zaman sudah berubah. Pada 2015, seluruh runtime Go yang saat itu sudah menjadi codebase matang pernah ditulis ulang secara semi-otomatis dari C ke Go. Salah satu maintainer membuat alat konversi C-ke-Go yang menargetkan subset C yang mereka pakai, sehingga hasilnya bisa dikompilasi dan menghasilkan output yang sama, lalu setelah itu kode hasilnya dipoles lagi oleh manusia agar lebih idiomatis dan lebih optimal sebagai Go
Sekarang tinggal minta saja ke model bahasa
Slide:
https://go.dev/talks/2015/gogo.slide#3
Ada kemiripan yang menarik juga
Karena manusialah yang menulis, memahami, menguji, dan memperbaiki bug pada alat konversinya, hasilnya bisa dipercaya
LLM itu tidak deterministik. Kalau Anda menyuruhnya mengonversi 10 kali secara independen, Anda akan mendapat 10 hasil berbeda, dan beberapa bisa sangat berbeda. Tidak ada cara memverifikasinya tanpa meninjau semuanya secara penuh setiap kali
Bukan berarti alat konversi deterministik buatan manusia itu sempurna atau bebas salah, tetapi tingkat kepercayaan yang bisa dibangun jauh lebih besar dibandingkan LLM
Commit yang ditautkan tampaknya tidak terlalu meyakinkan untuk mendukung judul ini. Ada branch tempat Claude sedang menulis ulang kode Zig ke Rust dalam skala besar, dan saat ini statusnya 773.950 baris ditambahkan dan 151 baris dihapus
[0]: https://github.com/oven-sh/bun/compare/claude/phase-a-port
Saya penasaran dengan skala pekerjaan ini, jadi saya ambil 5 teratas menurut cloc
Language files blank comment code
Zig 1298 79693 60320 571814TypeScript 2600 67434 115281 471122
JavaScript 4344 36947 37653 290873
C++ 583 27129 19117 215531
C 111 21577 83914 199576
Sebagai pendekatan yang mungkin berhasil tetapi lebih lambat, saya terpikir untuk mengikuti riwayat commit git seperti tahapan penguncian, sambil menerapkan maksud perilaku dari tiap commit
Dengan begitu, saya juga ingin tahu apakah implementasi Rust bisa melewati beberapa commit perbaikan bug tertentu karena masalahnya memang terhindari sejak awal
Mengingat Bun/Anthropic belakangan mengeluhkan waktu kompilasi Zig, yaitu karena PR peningkatan kecepatan kompilasi 4x hasil vibe coding tidak diterima, rasanya “menarik” melihat mereka ingin pindah ke bahasa yang kemungkinan waktu kompilasinya bahkan 4x lebih lama daripada Zig dasar
Saya pernah menulis kode yang mirip dalam Zig dan C++, dan kompilasi dingin di C++ beberapa kali lebih cepat, sedangkan kompilasi inkrementalnya di C++ nyaris instan
Menurut saya alasan utama proyek Rust lambat dikompilasi adalah penggunaan dependensi yang berlebihan dan penyalahgunaan metaprogramming di dalam kode
Zig tidak punya beberapa unit kompilasi, jadi kompilasinya tidak bisa diparalelkan
Saya sangat penasaran bagaimana porting AI ini akan berakhir. Saya terlibat di beberapa proyek aktif yang terhambat oleh bahasa atau framework yang dipakai, tetapi terlalu besar untuk ditulis ulang murni dengan tenaga manusia
Saya lebih berhasil dengan vibe coding Rust dibanding bahasa dinamis. Keketatannya compiler Rust seolah memaksa agen AI menghasilkan kode yang lebih baik. Saya tidak yakin, bisa juga cuma karena saya kurang akrab dengan Rust sehingga terasa seperti kerjanya lebih baik
Test harness itu wajib. Anda harus menjalankan tes di setiap iterasi untuk memastikan tidak merusak bagian lain
Saat ini saya sedang mem-port TypeScript ke Rust, dan belajar banyak dari prosesnya. Pekerjaan yang sedang berjalan bisa dilihat di sini https://github.com/mohsen1/tsz/
Saya bisa berbagi hal-hal yang saya pelajari
Cara saya mengatasi keterbatasan karena tidak bisa mereview detail kode adalah memastikan tes, tes integrasi, dan tes end-to-end mencakup semua hal yang saya pedulikan. Tanpa itu, saya tidak bisa yakin bahwa pekerjaan detailnya tidak ada yang terlewat
Saya juga menyuruhnya menjalankan benchmark dan stress test, serta menganalisis codebase untuk mencari potensi bottleneck. Setelah menemukan dan memperbaiki beberapa masalah, hasilnya jadi lebih baik. Terakhir, kalau disuruh melakukan review kritis, mencari peluang refaktor, dan semacamnya, ia cukup pandai membuat daftar hal berikutnya yang perlu diperbaiki
Menjalankan pemeriksa kebocoran memori dan alat analisis statis juga strategi yang bagus. Jika jumlah masalah yang ditemukan dengan cara ini mulai berkurang, mungkin kodenya tidak terlalu buruk. Setidaknya sudah mencapai optimum lokal tertentu
Tidak adanya code review memang terdengar cukup mengerikan, tetapi dalam coding berbantuan AI itu cepat sekali menjadi bottleneck terbesar. Menghilangkan bottleneck itu menakutkan, tetapi juga menaikkan jumlah kode yang memungkinkan dikerjakan beberapa tingkat sekaligus. Compiler yang ketat dan pengelolaan memori yang ketat membantu menghilangkan beberapa kategori bug
Dulu saya melakukan pekerjaan seperti ini dalam bahasa yang saya pahami. Begitu mulai rutin menangani commit yang lebih besar, review menjadi masalah
Saya rasa pekerjaan pada codebase besar seperti ini akan jauh lebih mudah dan lebih baik seiring waktu. Masalah utama yang saya temui dalam jenis rekayasa seperti ini adalah kecenderungan model untuk sengaja mengambil jalan pintas, hanya menguji jalur normal, dan menunda pekerjaan inti ke belakang
Banyak model tampaknya dibiasakan untuk menghemat penggunaan token. Cukup menjengkelkan, tetapi mudah ditangani dengan prompt lanjutan dan tes, dan sepertinya akan jadi masalah yang lebih kecil jika model disetel agar berperilaku lebih baik bahkan tanpa prompt tambahan
“Bisa juga cuma karena saya kurang akrab dengan Rust sehingga terasa seperti kerjanya lebih baik,” ya, saya rasa itu mungkin juga
Saya ingin Zig berhasil, tetapi karena belum 1.x, codebase besar seperti Bun tampaknya akan kesulitan menghadapi perubahan yang mematahkan kompatibilitas
Selain itu, Bun memakai fork Zig https://x.com/bunjavascript/status/2048427636414923250?s=20
Saya tidak mengerti kenapa mereka tidak menulis ulang claude-code ke Rust saja
Anthropic mengakuisisi tim Bun karena claude-code memakai Bun, dan sekarang sepertinya mereka ingin mem-port Bun dari Zig ke Rust mungkin karena Rust dianggap “lebih baik”. Dengan kata lain, mereka tampaknya ingin membuat claude-code jadi “lebih baik”, jadi saya tidak paham kenapa harus dibuat serumit ini
Dengan kemampuan LLM yang mereka miliki, rasanya mereka bisa langsung menulis claude-code dalam Rust dan menjadikannya sebaik mungkin
Bun juga mudah dilihat sebagai sekadar aksi pemasaran
Sampai saat ini, kebanyakan hal mengejutkan dari claude/codex masih terikat pada aplikasi yang dibangun di dalam batasan kondisi tepi dari library yang sudah ada. Model tersebut langsung memanfaatkan hasil kerja manusia yang luar biasa sampai saat ini, seperti Python,
requests,ffmpeg, dan semacamnyaTetapi saya menunggu saat ketika monster itu menjangkau keluar dari batasan itu, yaitu mulai menulis ulang, menambal, mengganti nama, dan membangun ulang library, DLL, dan biner. Pada titik itu, library akan meleleh hilang, dan aplikasi akan mengapung di atas pasir bergeser dari tumpukan teknologi yang lebih efisien, lebih aman, dan lebih terintegrasi, tetapi sepenuhnya tidak manusiawi
Ini jelas terdengar mengerikan dari sisi interpretabilitas atau keamanan, tetapi juga sulit untuk tegas mengatakan bahwa itu pasti tidak akan berhasil, terutama jika ada upaya terpusat yang benar-benar didedikasikan untuk itu. Juga belum jelas apakah slopifikasi total—penulisan ulang mekanis penuh atas puluhan tahun pengembangan dasar yang bertahap—dan interpretabilitas memang harus saling meniadakan
Opini di Lobste.rs
Sebagai referensi, ini yang dikatakan Jarred Sumner tentang hal ini di HN: dia bekerja di Bun dan ini adalah branch miliknya, serta menurutnya thread ini adalah reaksi berlebihan terhadap kode yang tidak berfungsi
Belum diputuskan bahwa akan ada penulisan ulang, dan sangat mungkin semua kode ini pada akhirnya dibuang
Intinya, dia ingin melihat seperti apa versi yang benar-benar berjalan, bagaimana performanya, seberapa sulit membuatnya lolos test suite Bun dan tetap dapat dipelihara, serta ingin membandingkan versi Rust dan versi Zig yang sama-sama layak secara berdampingan
Tafsir teknologi ala budaya populer sering kali bertumpu pada reaksi seketika
Pull request Bun secara umum juga cukup kacau: https://github.com/oven-sh/bun/pulls?q=is%3Apr+
Sebagian besar dibuat secara otonom oleh @robobun, memeriksa duplikasi lewat GitHub Actions (berbasis Claude), lalu direview oleh @coderabbitai dan @claude
Sementara itu CI rusak, dan @robobun akhirnya menutup sebagian PR buatannya sendiri karena dianggap duplikat dengan PR lain yang juga dibuatnya
Penggabungan ke main masih dilakukan manusia
Setahu saya Bun dipuji karena obsesi performa Jarred, jadi saya tidak menyangka dia akan membiarkan LLM berkeliaran seperti ini di codebase
Ini tidak masuk akal
Jika melihat “pemetaan idiom”,
unsafetersebar di mana-mana, dan sepertinya akan menghasilkan banyak kode yang tidak terasa seperti RustPemetaan
@fieldParentPtr("field", ptr)khususnya terlihat kasarNamun, tampaknya “phase A” pada dasarnya adalah terjemahan baris demi baris, lalu setelah itu akan dicoba refactor lewat prompt menjadi Rust yang lebih idiomatis dan mudah dipelihara
Masalahnya, desain bahasa bisa sangat mendorong arah implementasi dan memang sering begitu, sehingga besar kemungkinan akan muncul simpul-simpul kusut yang sulit diurai belakangan
Pada akhirnya, rasanya penulisan ulang manual cara lama akan menjadi jalan yang lebih baik
Terutama dengan daya dana seperti Anthropic, salah satu kenyamanan AI adalah ia tidak lelah meski harus refactor kode yang sama berulang kali
Terlepas dari migrasinya sendiri, cara yang mereka pilih terasa sangat menarik
docs/PORTING.mdyang ditautkan berisi sekitar 300 aturan porting, dan tampaknya terlalu banyak bagi LLM mana pun untuk “mengingat” semuanya dan mengikuti dengan setiaKarena Anthropic memiliki Bun, porting ini kemungkinan punya anggaran token yang nyaris tak terbatas, dan mungkin mereka mencoba “menjamin” semuanya dipatuhi dengan menjalankan agen sebanyak
jumlah file * jumlah aturanMereka juga membagi porting menjadi dua tahap: A mem-port tiap file secara terisolasi dan diperkirakan akan merusak kompilasi, B menghubungkan semuanya agar bisa dikompilasi
Pada phase A, agen diberi tahu bahwa kodenya “tidak perlu bisa dikompilasi”, dan tiap file hasil port diberi skor rendah/sedang/tinggi berdasarkan kualitas output
Rendah berarti logikanya salah, sedang berarti logikanya benar tetapi tidak bisa dikompilasi, tinggi berarti logikanya benar dan tampaknya bisa dikompilasi
Ini benar-benar kebalikan dari cara agen coding yang saya pahami dan gunakan, jadi saya penasaran dengan hasilnya
Menurut intuisi saya, jika dikatakan tidak perlu bisa dikompilasi dan tidak diberi “tujuan akhir” yang jelas, hasilnya akan menjadi sangat tidak bisa diprediksi, dan di phase B mereka akan harus me-review segunung kode yang tidak dapat dipercaya
Saya sempat grep cepat, dan dari 1279 skor kualitas output seperti ini, sekitar 3% rendah, 80% sedang, dan 17% tinggi
PORTING.mdsekitar 16k token dan fokus pada pekerjaan utamaItu tidak buruk untuk sub-agen baru, bahkan mungkin ideal
Saya penasaran apakah mereka benar-benar ingin beralih ke Rust, atau ini cuma uji coba LLM Anthropic
Jika Anthropic memindahkan Bun, salah satu proyek paling populer di Zig, ke bahasa lain, itu akan menjadi unjuk kekuatan yang cukup terang-terangan
Tentu saya tidak sepenuhnya percaya hipotesis dramatis ini, bisa juga ini sekadar upaya memamerkan produk dengan dana Anthropic yang tebal
Ini terlihat cukup menarik
Kumpulan aturan yang harus diproses sekaligus tampaknya mustahil diverifikasi tanpa siklus code review yang sangat besar
Token mungkin banyak, tetapi setelah transformasi seperti ini rasanya kode akan menjadi sangat sulit diverifikasi
Jika test juga harus melalui proses yang sama, saya jadi bertanya-tanya apa yang tersisa sebagai tolok ukur kebenaran
Meski begitu, eksperimennya sendiri luar biasa
Kalau melihat nasib para pembunuh Node.js, Deno memang menawarkan perbaikan kecil seperti sistem perizinan atau dukungan TypeScript bawaan, tetapi tidak berhasil mengguncang dunia, dan fitur-fitur ini bahkan sedang diimpor kembali ke Node.js
Dari pengalaman saya memakainya, pengalaman developernya tidak terasa jauh lebih baik, dan kadang malah lebih buruk karena ada alat hebat seperti pnpm
Mungkin memang lebih cepat, tetapi selama 5~6 tahun terakhir saya tidak benar-benar merasakan masalah performa Node.js dalam cakupan penggunaan saya
JSR juga tidak mengguncang dunia, dan komunitas justru membuat npmx yang kini memberi pengalaman lebih baik
Namun saya memang memakai standard library Deno, misalnya
@std/collections, karena cukup bagusBun terasa terlalu luas cakupannya sehingga sejak awal banyak tanda bahaya, tetapi saya sempat optimistis dengan hati-hati karena Jarred tampaknya ingin membuat runtime JS serbaguna terbaik, meski butuh bertahun-tahun
Tetapi setelah diakuisisi Anthropic dan melihat Jarred kini cukup banyak melakukan ~~vibe coding~~ pengembangan berbasis agen, ditambah kabar vibe porting ini, saya makin yakin bahwa ini bukan proyek yang akan saya pakai, meskipun hanya branch eksperimen
Jadi Node.js masih tetap mendominasi
Serius, fitur TypeScript bawaan dan SQLite itu mengesankan
Saya tidak sepenuhnya anti-AI; menurut saya vibe coding untuk script Python kecil atau webapp kecil guna menyelesaikan masalah yang sangat spesifik itu menyenangkan dan berguna
Tetapi pada proyek kompleks dengan banyak bagian bergerak dan pengguna, keyakinan saya makin menguat berulang kali bahwa “pengembangan berbasis agen” skala besar adalah kerugian bersih yang pada akhirnya membuat proyek tidak stabil dan menggembung, meski mungkin sementara mempercepat pengembangan fitur
Contohnya VSCode, Cursor, mise, Perplexity web UI
Apa sesulit itu membuat satu dropdown JS yang tidak tersendat saat di-scroll?
Saya berharap lebih banyak alat, library, dan proyek besar yang saya andalkan menyadari hal ini dan menerapkan kebijakan anti-AI yang lebih ketat
Karena keduanya memberi tekanan agar Node menjadi lebih baik
Node dulu bahkan sengaja tidak mengimplementasikan btoa
Tetapi pada akhirnya keduanya tampaknya akan tinggal menjadi catatan kaki
Ini benar-benar arah yang salah
Saya belum pernah melihat satu pun pemelihara Rust yang memelihara proyek Rust berukuran menengah, yaitu ratusan ribu baris atau lebih, dan puas dengan skalabilitasnya di codebase besar
Menurut saya Rust justru sangat bagus untuk codebase besar:
https://matklad.github.io/2023/03/28/rust-is-a-scalable-language.html
https://ferrous-systems.com/blog/rust-as-productive-as-kotlin/
Hanya saja untuk menanganinya secara efisien, Anda memang perlu cukup paham apa yang sedang Anda lakukan:
https://matklad.github.io/2021/09/05/Rust100k.html
Dalam konteks ini saya kurang tahu bagaimana Zig dibandingkan dengan Rust
TigerBeetle punya pendekatan desain yang cukup khusus
Saya juga tahu beberapa kasus di mana program Rust 20 ribu baris mengimplementasikan fungsi inti dari program Go 300 ribu baris
Jadi ini memang tidak persis memenuhi syarat yang disebutkan
Tetapi di kisaran 10 ribu hingga 100 ribu baris, sebagai pemelihara saya sangat puas dengan Rust
Ukuran seperti ini cukup kecil agar program tetap fokus, tetapi cukup besar untuk mewujudkan satu ide inti dengan setia
Pada ukuran ini, bahasa dan tool-nya sama-sama menjadi aset besar, setidaknya dalam pengalaman pribadi saya
cargo-nextestsaat ini memiliki 84 ribu baris kode Rust, tidak termasuk komentar dan baris kosong, dan sebagai pemelihara tunggal saya merasa tidak mungkin menulisnya dalam bahasa lain sambil tetap memenuhi standar kualitas pribadi sayaMungkin karena ini: https://github.com/oven-sh/bun/issues/28001
Ini bukan masalah keamanan memori temporal