Program Build It Yourself yang Dibuat Sendiri

• Cara pandang lain tentang dependensi

  • Mengusulkan perspektif baru tentang dependensi. Perlu mengurangi penggunaan dependensi yang berlebihan dan beralih ke arah menulis kode sendiri.

• Masalah dependensi

  • "Kelelahan dependensi" adalah siklus tanpa akhir dari update, patch, audit, dan dependensi transitif yang dipasang developer demi produktivitas.
  • JavaScript dan Rust sangat rentan terhadap masalah dependensi. Misalnya, proyek Tokio baru mencakup 28 crate, dan proyek Rocket meningkat hingga 172 crate.

• Masalah ukuran terminal

  • Crate terminal_size menyediakan fungsi sederhana untuk mengukur ukuran terminal, tetapi memerlukan beberapa crate tambahan.
  • Akibatnya, muncul situasi di mana ribuan fungsi lain harus dikompilasi.

• Kebutuhan akan dependensi

  • Karena dibangun di atas library abstraksi platform, update diperlukan untuk menghindari duplikasi kode dan mengurangi waktu kompilasi.
  • Dependensi juga sering menjadi penyebab utama masalah keamanan.

• Tujuan kode

  • Kode seharusnya ditulis dengan cara yang tidak memerlukan update. Di ekosistem Rust, kode yang stabil justru dirugikan.

• Keuntungan menulis kode sendiri

  • Dengan menulis kode sendiri, tidak perlu crate baru dan kebutuhan pemeliharaan berkurang.
  • Alat seperti ChatGPT dapat digunakan untuk dengan cepat menulis implementasi tanpa dependensi.

• Open source dan budaya perusahaan

  • Budaya code review perusahaan memengaruhi perangkat lunak open source.
  • Menggunakan library baru dianggap sebagai hal yang positif.

• Perlunya perspektif baru

  • Engineer yang menulis sendiri fitur kecil seharusnya dipuji.
  • Kita perlu bersikap curiga terhadap graph crate yang besar.

• Library penting

  • Ada juga library penting yang menyelesaikan masalah kompleks. Misalnya, library grafis atau implementasi protokol.

• Pentingnya membangun sendiri

  • Kita perlu merayakan tindakan membangun sendiri ketika memang tepat.
  • Penulis library yang membangun library open source dengan dependensi sedikit atau tanpa dependensi layak mendapat penghargaan.

• Kesimpulan

  • Kita harus beralih ke arah mengurangi dependensi dan menulis kode sendiri.
  • minijinja adalah contoh yang meminimalkan dependensi, dengan hanya bergantung pada serde.

[GN⁺]

Komentar Hacker News

• Saya suka bahasa Rust, tetapi tidak suka masalah dependensinya. Pengelolaan dependensi di C++ lebih baik. Di C++ saya bisa mengendalikan dependensi sendiri, tetapi di Rust terlalu banyak dependensi hingga akhirnya menyerah. Dari sisi keamanan juga, saya tidak tahu apa yang sebenarnya saya distribusikan. Rust tidak punya kompatibilitas ABI dan juga minim budaya shared library. Ini merusak model distribusi paket OS.

• API terminal tidak stabil. ioctl TIOCGWINSZ tidak distandardisasi, dan fungsi POSIX tcgetwinsize() baru ditambahkan pada 2024. Sisi Windows bahkan lebih rumit.

• Saya menghidupkan kembali web app yang dibuat pada 2006. Untuk mempelajari teknologi CI/CD baru, saya merancang proses deployment aplikasi itu secara berlebihan. Saya memakai PHP dan MySQL, dan menulis sebagian besar kodenya sendiri. Menghidupkan kembali aplikasi berusia 19 tahun itu hanya butuh satu jam. Sebaliknya, aplikasi Spring Boot yang dipakai di tempat kerja sekarang sulit diperbarui karena masalah dependensi.

• NodeJS sangat memengaruhi karier saya, tetapi NPM menimbulkan banyak masalah. Saat mencoba menambahkan dependensi baru, sering bentrok dengan dependensi lain. Dalam kasus Expo, bahkan proyek dasar React Native punya masalah tidak bisa build di Android. Ini memberi saya kepercayaan diri karena bahkan proyek besar pun bisa merilis template yang tidak berfungsi.

• Ekosistem Rust punya lebih banyak dependensi dibanding Go. Di Go, interface dipenuhi secara implisit sehingga tidak perlu dependensi tambahan.

• Abstraksi library punya biaya tersembunyi. Jika paket mengubah desainnya, akan muncul ketidakstabilan. Hal yang sederhana bertahan paling lama. Saya melihat masalah serupa bukan hanya di Rust, tetapi juga di bahasa lain.

• ChatGPT atau Cursor lebih cepat jika dipakai untuk membuat implementasi tanpa dependensi. Banyak dependensi pada layanan SaaS/3rd party sebenarnya adalah masalah yang sudah terselesaikan.

• Flask dan Bottle punya fungsi yang mirip, tetapi Flask menjadi lebih populer. Bottle berupa satu file tunggal tanpa dependensi sehingga mudah disalin ke dalam proyek. Namun, karena tidak mengikuti praktik Python modern, ia terasa kuno.

• Kita butuh engineer yang mampu mengembangkan solusi sendiri. Sering kali lebih mudah membuat solusi yang lebih baik daripada library yang sudah ada. Saya pernah menulis parser untuk varian Markdown di sebuah proyek, tetapi rekan tim tidak mau memakainya karena alasan maintainability.

• Ada masalah ketika kita hanya memakai satu fungsi tetapi harus mengompilasi ratusan fungsi. Di sebuah proyek yang memperbarui dependensi 3rd party, kami ternyata hanya memakai satu metode dari library matematika. Saya menyarankan engineer untuk melihat halaman Wikipedia dan menulis sendiri metodenya. Masalahnya bukan pada penggunaan dependensi 3rd party itu sendiri, tetapi perlunya konsep untuk mengambil hanya sebagian kecil dari sebuah library. "Microframework" mungkin bisa menjadi solusinya.