Mengapa Anda Harus Mendistribusikan Alat sebagai Binary Statis Standalone

• Dengan mendistribusikan alat sebagai binary statis standalone, pengguna dapat langsung memakainya tanpa perlu memasang lingkungan pengembangan atau toolchain terpisah
• Proses kompilasi berfungsi sebagai lapisan pengaman tambahan yang menurunkan kemungkinan kode bermasalah terdistribusi
• Alat berbasis bahasa interpreter memiliki beban pemeliharaan yang besar, seperti pemasangan berbagai dependensi dan pemborosan ruang disk, serta instal ulang berulang saat upgrade
• Semakin banyak dependensi, semakin besar pula kerentanan keamanan dan permukaan serangan, sehingga risiko peretasan atau masalah pemeliharaan lebih mudah muncul
• Binary statis berbasis bahasa terkompilasi tidak terpengaruh oleh perubahan lingkungan eksternal, sehingga tetap menjamin penggunaan yang stabil setelah didistribusikan

---

Keunggulan Distribusi Binary Statis Standalone

Bisa Langsung Digunakan Tanpa Instalasi

• Seperti kasus OpenAI yang membangun ulang Codex dengan Rust dan meninggalkan TypeScript, jika Anda mendistribusikan satu binary yang ditulis dalam bahasa terkompilasi, pengguna dapat langsung menjalankannya tanpa perlu memasang toolchain tambahan
• Keunggulan terbesarnya bukan kecepatan atau efisiensi, melainkan alat bisa langsung digunakan tanpa instalasi

Pengaman Tambahan dari Compiler

• Pemeriksaan pada tahap kompilasi mengurangi kemungkinan kode bermasalah terdistribusi
• Sebagai contoh, Google Cloud CLI yang berbasis Python pernah beberapa kali didistribusikan dalam keadaan tidak bisa dijalankan
• Tim besar pun sulit menghindari masalah ini, dan bagi tim kecil akan lebih sulit lagi mendistribusikan alat berbasis bahasa interpreter secara stabil

Tidak Memerlukan Dependensi Toolchain

• Alat berbasis bahasa terkompilasi cukup didistribusikan sebagai satu binary, sedangkan alat berbasis bahasa interpreter seperti Python, Ruby, dan TypeScript wajib memiliki lingkungan pengembangannya
• Seperti mdl (markdown linter) yang ditulis dengan Ruby, instal ulang diperlukan setiap kali lingkungan pengembangan (Ruby) di-upgrade
• Saat memakai markdownlint berbasis JavaScript, perlu memasang npm dan lebih dari 44 dependensi

Masalah Pemborosan Ruang Disk

• Aider, coding assistant FOSS yang populer, ditulis dengan Python dan saat dipasang lewat Homebrew akan menambahkan 51 paket
• Penggunaan disk nyata bertambah lebih dari 3GiB, yang lebih besar daripada ukuran kebanyakan distribusi Linux
• Sebaliknya, package manager uv yang ditulis dengan Rust bisa dipasang hanya dengan satu binary berukuran 35MiB, tanpa perlu Rust itu sendiri maupun rustup

Peningkatan Kerentanan Keamanan

• Semakin banyak dependensi alat, semakin luas permukaan serangan dan semakin tinggi kemungkinan terekspos pada kerentanan keamanan
• Paket Codex dari OpenAI memiliki 24 dependensi langsung dan 184 dependensi tidak langsung
• Bahkan jika OpenAI mengaudit semua dependensi, karena versi dependensi tidak dikunci, pembaruan di masa depan tetap bisa memunculkan masalah seperti kerentanan, paket berbahaya, atau gangguan fungsi

Kemudahan Pemeliharaan

• Alat berbasis bahasa interpreter seperti JavaScript, TypeScript, dan Python akan berhenti berfungsi jika dependensi dihapus
• Seperti insiden left-pad, penghapusan satu paket saja dapat melumpuhkan layanan dan alat dalam skala besar
• Bahasa terkompilasi hanya memerlukan dependensi saat build, sehingga meski repositori eksternal hilang setelahnya, alat tetap bisa terus berjalan normal

Pengalaman Penulis

• Penulis pernah membuat alat seperti adb-enhanced dengan Python, lalu meng-open-source-kan berbagai alat seperti gabo dan wp2hugo dengan Go
• Mengembangkan alat standalone dengan Python atau TypeScript tidak lagi dipertimbangkan
• Sangat disarankan memakai bahasa yang memungkinkan distribusi binary statically linked (Rust, Go, C++, dll.)

Kesimpulan

• Alat standalone sebaiknya dikembangkan dengan bahasa terkompilasi seperti Rust, Go, dan C++
• Alat tersebut harus didistribusikan dalam bentuk binary statis dengan dependensi eksternal seminimal mungkin

[rikko]

Saya cukup banyak berempati dengan masalah pemborosan ruang disk ini...
Saya mengelola AKS, dan setiap kali melihat aplikasi Python dengan image container yang ukurannya melewati 1GB, kepala saya rasanya pusing.
Sekarang saya biasanya cuma mengambil Dockerfile lalu mengecilkan ukurannya sendiri sebelum diunggah lagi, dan kalau tidak bisa saya turunkan sampai di bawah 500MB, ya saya menyerah saja wkwk

[eususu]

Ada paket yang dependensinya pada pytorch+cuda cuma berbeda di versinya saja... benar-benar kacau.
Padahal fiturnya juga nyaris tidak ada, tapi untuk tiap daemon kecil dependensinya terpasang sampai hampir 2 GB..

[rikko]

Kalau runtime CPU yang dipakai cuma untuk inferensi sederhana, kondisinya masih agak mendingan. Tapi karena layanan LLM yang dituntut belakangan ini, trafik naik ya naik, kapasitas juga ikut membengkak, jadi tiap hitung biaya rasanya pengin ngamuk wkwk