- Dengan pengembangan berbantuan AI, kriteria pemilihan bahasa bergeser dari kecepatan menulis manusia ke kemampuan AI untuk memperbaiki dan performa runtime
- Pada 2026, Claude Opus 4.7, GPT-5.5, Gemini 3.1, dan DeepSeek V4 melampaui 80% di SWE-bench Verified
- Rust membantu perbaikan mandiri AI lewat loop umpan balik kompilator, dan Go serta Swift juga menguntungkan agen berkat pemeriksaan tipe yang cepat
- Transisi besar sudah berlangsung, seperti porting kompiler TypeScript ke Go, kompiler C berbasis Rust, Rue, dan porting mesin JavaScript Ladybird
- Ekosistem Python dan JavaScript juga makin bergantung pada tool dan wrapper Rust, tetapi pengecualian seperti Prisma, PyTorch, dan bahasa-bahasa kecil tetap ada
Kriteria pemilihan bahasa yang berubah karena pengembangan berbantuan AI
- Pilihan default untuk proyek baru selama ini adalah Python atau TypeScript
- Karena ekosistemnya besar, kumpulan talenta luas, dan demo bisa dibuat cepat
- Rust, Go, dan C++ bisa memberi performa 10–100 kali lebih tinggi, tetapi waktu belajar, pasar talenta yang kecil, dan sistem build yang rumit menjadi biaya tambahan
- Karena itu, banyak tim merilis versi Python terlebih dulu dan berkata akan “meningkatkan performanya nanti”, tetapi dalam praktiknya sering tetap seperti itu
- Saat AI mulai menangani bahasa yang sulit, pertukaran ini mulai goyah
- Dalam memilih bahasa, bobot “apakah manusia bisa menulisnya cepat” mengecil, sementara “apakah AI bisa menulis dan memperbaikinya dengan baik” serta performa runtime menjadi lebih penting
Bahasa yang sulit lebih dulu menjadi mudah bagi AI
- Dua tahun lalu, GPT-4 masih berada pada tahap mengarang nama crate yang tidak ada saat menulis fungsi Rust
- Pada April 2026, Claude Opus 4.7, GPT-5.5, Gemini 3.1, dan DeepSeek V4 melampaui 80% di SWE-bench Verified dalam rentang beberapa minggu
- Berbagai lab kini secara eksplisit mengoptimalkan pekerjaan sistem
- bug konkurensi
- race condition
- cacat arsitektur yang ditemukan pada tahap perencanaan
- CtrlAltDwayne menilai kekuatan Rust pada 2026 bukan terutama pada keamanan memori atau performa, melainkan pada loop umpan balik kompilator
- AI menulis Rust lebih baik daripada C++
- pesan error kompiler Rust menjadi sinyal yang membantu model memperbaiki dirinya secara real time
- Rust bekerja seolah-olah merupakan bahasa yang “kebetulan dirancang” 10 tahun lebih awal untuk pengembangan berbantuan AI
- Logika yang sama, walau dalam derajat berbeda, juga berlaku untuk Go dan Swift
- Sistem tipe yang kuat dan loop kompilasi/pemeriksaan yang cepat memberi agen siklus iterasi yang rapat
- Bahasa sistem yang sulit bagi manusia justru bisa menjadi target yang lebih mudah bagi agen
Contoh yang benar-benar sudah dirilis
-
Porting kompiler TypeScript Microsoft ke Go
- Microsoft merilis TypeScript 7.0 beta dan mem-porting codebase TypeScript berusia 10 tahun ke Go
- TypeScript 7.0 beta kira-kira 10 kali lebih cepat daripada 6.0
- Menurut penilaian Anders Hejlsberg, Go memberikan sebagian besar manfaat performa dengan hanya sebagian dari biaya rekayasa
- Salah satu organisasi JS/TS terbesar memilih bahasa yang lebih sulit tetapi lebih cepat untuk tool andalannya, menandakan perhitungan biaya-manfaat telah berubah
-
Kompiler C berbasis Rust yang dibuat dengan 16 agen Claude
- Peneliti Anthropic Nicholas Carlini mengorkestrasi 16 agen Claude secara paralel untuk menulis kompiler C produksi dalam Rust
- Skalanya 100 ribu baris dan dapat mem-boot Linux 6.9 di x86, ARM, dan RISC-V
- Ia dapat mengompilasi QEMU, FFmpeg, SQLite, PostgreSQL, Redis, dan bahkan menjalankan Doom
- Total biayanya kurang dari 20 ribu dolar untuk hampir 2.000 sesi Claude Code
- Kompiler C yang ditulis dalam Rust dulu adalah pekerjaan setingkat tesis pascasarjana, tetapi kini bukan lagi sesuatu yang sepenuhnya luar biasa
-
Rue karya Steve Klabnik
- Steve Klabnik, salah satu penulis The Rust Programming Language dan veteran Rust selama 13 tahun, bersama Claude membuat bahasa sistem baru bernama Rue dalam waktu 2 minggu
- Hasilnya kira-kira 70 ribu baris Rust
- Ia menyatakan bahwa pekerjaan 2 minggu ini melangkah lebih jauh dibanding upaya-upaya sebelumnya yang menghabiskan satu atau dua bulan
-
Porting mesin JavaScript Ladybird ke Rust
- Andreas Kling, pendiri browser Ladybird dan engineer C++, memberi ratusan prompt kecil ke Claude Code dan Codex untuk mem-porting mesin JavaScript Ladybird dari C++ ke Rust dalam 2 minggu
- Hasilnya sekitar 25 ribu baris Rust, dan mencapai kesetaraan byte demi byte dengan sumber C++ aslinya
- Gabungan test262 dan pengujian Ladybird menunjukkan tidak ada regresi pada lebih dari 65 ribu pengujian
- Ia menyebut pekerjaan yang sama akan memakan waktu berbulan-bulan jika dilakukan manual
Logika “ekosistem” yang mulai melemah
- Argumen terkuat Python dan JavaScript selama ini bukan pada bahasanya sendiri, melainkan pada ekosistem
- Ada fondasi seperti FastAPI, Django, PyTorch, React, Next.js, dan 4 juta paket di npm
- Tim bisa merilis fitur dalam hitungan hari karena ekosistem sudah menyelesaikan 90% masalah
- Keunggulan ini sangat menentukan selama 10 tahun terakhir, tetapi mulai melemah dalam 2 tahun belakangan
- Bahkan di dalam ekosistem Python, ketergantungan pada komponen berbasis Rust terus meningkat
- Seluruh core validasi
pydantic adalah library Rust
- Polars, alternatif pandas, ditulis dalam Rust
- Hugging Face tokenizers dan orjson juga berbasis Rust
- Menurut survei Python JetBrains 2025, penggunaan Rust dalam ekstensi biner Python naik dari 27% menjadi 33% hanya dalam satu tahun
- Fondasi tool pengembangan juga bergerak ke arah yang sama
- Astral, yang didirikan Charlie Marsh pada 2022, merilis ruff, uv, dan ty yang ditulis dalam Rust, dan unduhan bulanan ketiga tool itu tumbuh dari 0 menjadi ratusan juta
- Pada 19 Maret 2026, OpenAI mengakuisisi Astral dan menilai uv menghemat sekitar 1 juta menit waktu komputasi Codex per minggu
- 10 minggu sebelumnya, Anthropic mengakuisisi Bun
- Bun mencatat 7 juta unduhan bulanan dan 89 ribu bintang GitHub, serta disebut sebagai “infrastruktur esensial untuk software engineering yang dipimpin AI”
- VoidZero milik Evan You merilis Rolldown-Vite
- Bundler Rust ini memangkas build GitLab dari 2,5 menit menjadi 40 detik dan menurunkan penggunaan memori hingga seper seratusnya
- Lee Robinson, VP produk di Vercel, mengatakan bahwa “JS telah mencapai puncak optimisasi”
- Paket yang dipakai dari Python dan JavaScript makin sering hanya menjadi wrapper atas kode yang ditulis dalam bahasa yang dulu dianggap terlalu sulit untuk langsung dirilis
- Jika sekarang bahasa-bahasa itu bisa dipakai langsung untuk merilis produk, wrapper mulai terlihat sebagai overhead
Perubahan ketika porting menjadi lebih mudah daripada patching
- Siklus baik dalam ekosistem open source selama ini berpusat pada patch
- Memilih Python karena mudah
- Menemukan bug di dependency
- Memperbaikinya dan mengirimkannya ke upstream
- Ekosistem menjadi lebih sehat
- Agen kini menggeser satuan kontribusi dari patch ke porting
- Pada Januari, pencipta Flask Armin Ronacher memakai agen untuk mem-porting library Rust MiniJinja ke Go
- Total waktu eksekusinya 10 jam
- Dari itu, 3 jam diawasi dan 7 jam berjalan tanpa pengawasan
- Waktu manusia yang benar-benar terpakai hanya 45 menit
- Biaya API-nya 60 dolar
- Jika mem-porting library antarbahasa menjadi pekerjaan 45 menit, logika untuk mengirim perbaikan ke library milik orang lain pun melemah
- Bukan lagi “kalau bisa patch, mengapa tidak fork”, melainkan “kalau bisa fork, mengapa patch”
- Armin Ronacher melihat nilai sedang bergeser dari kode ke pengujian dan dokumentasi
- Test suite yang bagus bisa lebih berharga daripada kodenya sendiri
- Siklus yang membangun PyPI dan npm masih berjalan sekarang, tetapi belum jelas apakah akan tetap sama pada 2028
Pengecualian yang tetap ada
- Tidak semua perubahan bergerak hanya ke satu arah
- Dalam beberapa kasus, pilihan lama tetap benar
- Prisma menghapus query engine Rust dan beralih ke core TypeScript/WASM
- Ukuran bundle berkurang 85% dan kueri menjadi hingga 3,4 kali lebih cepat
- Biner Rust native kurang menguntungkan untuk runtime serverless
- PyTorch masih menguasai sekitar 85% riset deep learning
- Karena bobot model tidak terpengaruh oleh bahasa pembungkusnya, posisi ini tidak mudah berubah
- AI juga tidak menangani semua bahasa sistem dengan kualitas yang sama
- Bahasa yang lebih kecil seperti Zig, Haskell, dan Gleam saat ini belum memiliki kualitas generasi AI setara Rust atau Go
- Data pelatihan menentukan sejauh mana model bisa membantu
- Rust dan Go berada pada posisi yang menguntungkan karena sangat banyak tersedia di GitHub
- Zig, Haskell, dan Gleam masih berada di sisi kurva yang kurang menguntungkan
Mengapa perubahan ini bisa bertahan
- Logika pertahanan lama Python dan TypeScript pada dasarnya adalah pertahanan atas developer experience
- Keduanya dipilih karena meminimalkan friksi antara ide manusia dan produk yang dirilis
- Rust bukan bahasa yang lambat saat runtime, melainkan bahasa yang lambat ketika harus merilis pada jam 2 pagi
- Kini agen mulai mengambil alih bagian yang sulit
- Peran manusia bergeser dari “menulis kode” menjadi “merancang sistem dan meninjau output”
- Dalam arus ini, kenyamanan sintaks Python menjadi makin kurang penting di setiap percabangan keputusan
- Keunggulan runtime dari bahasa yang lebih sulit terus terakumulasi setiap hari layanan berjalan di produksi
- Dalam tulisan Februari A Language For Agents, Armin Ronacher berpendapat bahwa biaya coding turun drastis sehingga luasnya ekosistem menjadi kurang penting
- Selama 20 tahun terakhir, pemilihan bahasa dibentuk oleh kendala bahwa “manusia menulis kode, dan manusia lambat dalam bahasa tingkat rendah”
- Kendala ini mulai menghilang
- Dalam survei Stack Overflow 2025, Rust menjadi bahasa paling dikagumi selama 10 tahun berturut-turut dengan 72%
- Gleam 70%
- Elixir 66%
- Zig 64%
- Preferensi itu sudah ada sejak lama, dan kini tool mulai mengejarnya
Langkah berikutnya menuju bahasa yang mudah bagi agen
- Karpathy mengatakan pada Februari bahwa LLM mengubah seluruh lanskap batasan dalam software
- Ia melihat tandanya dalam arus porting dari C ke Rust
- Ia menambahkan bahwa bahkan Rust pun belum tentu mendekati bahasa target optimal untuk LLM
- Pemenang saat ini mungkin hanya titik awal, dan bentuk akhirnya bisa masih jauh di depan
- @RealRichomie mengatakan pada 24 April bahwa masa depan pemrograman bukan menuju bahasa yang paling mudah bagi manusia, melainkan bahasa yang paling mudah bagi agen
- Para engineer merilis aplikasi Mac tanpa benar-benar mengenal Rust atau Tauri sebelumnya
- Hasilnya berukuran sekitar sepersepuluh versi Electron dan memiliki performa runtime yang lebih tinggi
- Manusia mencapai hasil itu tanpa perlu mempelajari Rust
- Proyek berikutnya tidak harus menjadikan Python sebagai default
1 komentar
Pendapat Hacker News
Jika setuju dengan anggapan bahwa alat coding LLM itu seperti kompiler non-deterministik, maka cukup masuk akal untuk memilih bahasa yang performanya sebaik mungkin
Tentu ada banyak pengecualian seperti library atau keunggulan native per bahasa, tetapi setelah bekerja sekitar sebulan dengan C++, satu-satunya hal yang melambat karena pilihan bahasa hanyalah waktu kompilasi
Aku kaget setelah membaca komentar-komentar awal tapi tidak melihat pembahasan soal data pelatihan. Kode Python sangat banyak di data pelatihan
AI mungkin saja bisa menulis Brainfuck, tetapi menurutku hasilnya tidak akan sama seperti saat memakai Python
Pertanyaan lanjutannya adalah: sekarang kalau sudah ada AI, kenapa kita harus peduli pada bahasa sebelum benar-benar perlu?
Sebagian besar kutulis dengan Claude Code, dan Claude benar-benar sangat bagus menangani Perl. Aku bilang jangan sentuh CPAN dan pakai hanya library standar Perl, ternyata sudah ada HTTP client, TLS, sampai JSON bawaan, dan itu bisa menggantikan hal-hal yang biasanya akan kubuat dengan shell script dengan cara yang sangat stabil dan mudah
Karena Perl tidak banyak berubah dan data latihnya juga banyak, Claude tampaknya cukup bagus memakai Perl dalam situasi yang biasanya membuat orang terpikir untuk memakai shell script
Datanya ada di sini: https://gertlabs.com/rankings?mode=agentic_coding
Aku pernah membuat codebase Python besar dengan AI, dan LLM terus salah menebak argumen atau bentuk dictionary. Unit test atau alat seperti pydantic memang membantu, tetapi lebih baik menghindari jenis runtime error seperti itu sejak awal
Hasilnya juga bagus pada bahasa yang kode publiknya relatif sedikit. Hambatan yang lebih besar adalah LLM suka meniru idiom umum bahasa target, dan pada bahasa yang terasa “enterprise” seperti Java atau C#, kode boilerplate yang tidak berguna bisa langsung meledak jumlahnya. Akibatnya hasil bisa melampaui ukuran context window yang masih bisa dipakai dan kualitasnya menurun
Tetapi jika agen membuat kode, mencoba mengompilasinya, melihat pesan error yang rinci, lalu menyempurnakan kode berdasarkan pesan itu, hasilnya akan berkualitas lebih tinggi. Diagnostik rustc sangat bagus, dan meskipun Python atau JavaScript/TypeScript jauh lebih banyak, sekarang kode Rust di internet juga sudah cukup banyak
Kenapa Python? Karena aku sudah memakainya lebih dari 10 tahun, tahu cara debug-nya, dan bisa mencium dalam 10 detik apakah agen sedang menulis sesuatu yang bisa berujung jadi masalah besar
Dengan bahasa lain aku tidak bisa, dan harus banyak belajar ulang. Walaupun AI bisa memuntahkan kode dengan cepat, aku jadi cenderung memilih Python karena masih terasa ada tingkat kendali. Kalau pakai Go atau Rust, rasanya bukan lagi AI-assisted programming, melainkan “vibe coding” dengan produk sepenuhnya didorong YOLO
Bagian keamanan memori memang harus kupelajari karena aku belum tahu apa yang “benar”, tetapi selain itu semuanya lancar
Sintaks lama-lama memudar ke latar belakang dan kita jadi fokus ke hal-hal yang lebih tingkat tinggi serta mengeksplorasi jalur baru. Kalau dicoba sekali, mungkin akan terasa menyenangkan karena ternyata begitu banyak pengalaman yang bisa dipindahkan
Kalau AI yang menulis untukmu, kenapa masih pakai otak?
/s
Kenapa berhenti pada menyuruh AI memakai Rust? Kalau semuanya sudah vibe coding dan code review juga tak lagi dilakukan, sekalian saja suruh LLM merancang bahasa yang super ringkas dan super padat yang dibuat hanya demi meminimalkan penggunaan token dan kecepatan
Di akhir komentar ini ada /s yang hanya sebagian dimaksudkan
Sedikit di luar topik, tapi aku benar-benar tidak paham kenapa orang masih memposting di Medium
Pengalaman membacanya mengerikan. Popup layar penuh secara harfiah menutupi kalimat yang sedang kubaca, jadi aku bahkan tidak bisa menamatkan artikel ini
Apa ada insentif yang tidak kulihat?
Tidak ada apa pun yang dibaca di browser yang pada akhirnya bisa memberi semua orang pengalaman membaca yang luar biasa dan paling baik secara sama rata. Model web modern sendiri bertentangan dengan itu
Halaman HTML biasa tanpa CSS hampir merupakan pengalaman membaca yang nyaris sempurna. Masalahnya, hampir tak ada yang menerbitkan seperti itu. Web sudah menjadi platform penerbitan yang para penulisnya saling bersaing dan peduli pada hal-hal lain. Protokol plain text yang berada di bawah kendali pengguna lebih dekat ke “pengalaman membaca terbaik untuk semua orang”. Web sebenarnya bisa begitu, tetapi kebanyakan tidak
Aku sudah berhenti mencoba membaca tulisan panjang di browser. Kalau plain text terkait, bahkan structured text pun, bisa diekstrak dengan mudah lalu kubaca di editor milikku sendiri, kenapa harus dibaca di browser? Aku bisa mengendalikan font, warna, navigasi, dan lain-lain. Browser itu media distribusi, bukan lingkungan membaca. Memperlakukannya sebagai lingkungan membaca hanyalah kebiasaan, bukan keharusan
Sudah lama juga aku tidak menulis apa pun yang lebih dari tiga kata di luar editor. Spell check, tesaurus, pencarian etimologi, terjemahan, akses ke semua catatanku, sampai integrasi LLM, semuanya sudah ada di sana. Coba saja suatu hari, rasanya akan sangat membebaskan. Setelah itu kamu juga bisa berhenti membaca tulisan panjang di browser
Medium sudah lama melakukan upaya yang cukup serius untuk membayar penulis. Modelnya berbeda dari Substack, tetapi itulah alasannya
Aku melihatnya mirip cara memandang paywall koran. Aku tidak suka, tetapi paham kenapa itu ada
Dugaan yang paling masuk akal adalah inersia. Ada orang-orang yang sangat loyal pada merek dan merasa harus bergerak mengikuti apa yang orang lain lakukan dan bagaimana caranya
Padahal sebenarnya tempat postingnya tidak penting dan cukup beri URL saja, tetapi tidak semua orang bertindak seperti itu
Terlihat seperti evolusi terbaru dari platform blog yang ramah penulis. Lebih mudah dibundel dalam bentuk newsletter daripada WordPress, dan lebih mudah juga dimonetisasi lewat tier berbayar
Coba pakai frontend alternatif Medium bernama Scribe, jauh lebih baik:
https://scribe.rawbit.ninja/@NMitchem/if-ai-writes-your-code...
https://sr.ht/~edwardloveall/Scribe/
https://libredirect.github.io/
Python punya ekosistem yang jauh lebih matang daripada Rust, terutama di ranah AI/machine learning
Aku pernah menemukan crate Rust yang mengklaim mengimplementasikan algoritma machine learning tertentu, tetapi ternyata tidak bekerja dengan benar. Meski begitu, aku tetap bisa menulis implementasi penggantinya dengan Claude
Bersama AI, menurutku memaksa ketepatan di level sistem tipe adalah ide yang bagus, jadi aku lebih sering memilih bahasa seperti C# atau Rust daripada Python. Meski begitu, untuk beberapa hal Python jelas merupakan alat yang tepat
Aku sebenarnya bisa saja memakai Rust, tetapi kalau hasilnya berhasil, orang lain akan mendapat nilai lebih besar dari memakai satu toolchain, jadi Go terasa lebih tepat
Alasan utamanya adalah harus bisa dibaca saat diperlukan. Dan ekosistem penerima memang punya bahasa yang diharapkan. Beberapa komunitas data science memilih R, MatLab, Julia, Python, atau Mojo bukan karena mana yang secara teknis paling unggul, melainkan karena itulah yang dipakai rekan-rekan mereka
Dugaanku, bahasa bertipe sering punya language server yang lebih cepat dan lebih baik, sehingga alat bisa mengubah kode dengan lebih efisien
Saat manusia perlu turun tangan untuk menyelidiki atau memperbaiki kode juga, typing yang kuat membuat kita jauh lebih mudah menemukan arah di dalam kode spageti
Dengan begitu kita dapat keunggulan garbage collection dan tipe yang kuat
Untuk saat ini alasannya persis sama seperti alasan orang memilih Python saat menulis sendiri. Lebih banyak orang tahu Python daripada bahasa seperti Zig, jadi manusia bisa lebih mudah membaca dan mengubah kodenya
Aku paham maksud artikelnya, tetapi menurutku kita belum sampai ke tahap itu
“Aplikasi yang dirilis dalam bahasa yang tidak diketahui siapa pun di tim” kedengarannya mantap. Di masa depan yang tidak terlalu jauh kita akan menoleh ke belakang pada hal seperti ini
Pernyataan bahwa “peneliti Anthropic Nicholas Carlini mengoordinasikan 16 agen Claude paralel untuk menulis kompiler C produksi dalam Rust” itu tidak benar
Kompiler tersebut menghasilkan kode yang jauh lebih buruk daripada gcc/clang sehingga pada dasarnya tidak berguna