Hingga Menjadi Dune, Sistem Build yang Lebih Baik untuk OCaml

• Jane Street membuat Jenga karena tidak puas dengan OMake, tetapi adopsi eksternalnya lemah; sementara Jbuilder, yang dibuat sebagai lapisan kompatibilitas, tanpa diduga tumbuh menjadi tool dasar bagi komunitas OCaml
• Daya tarik awal Jbuilder bukanlah fiturnya, melainkan kecepatan dan portabilitas; pada proyek Jane Street, kompilasi sekitar 5 kali lebih cepat dibanding OCamlbuild mendorong adopsinya
• Jbuilder berkembang menjadi sistem build lengkap melalui kerja sama dengan OCaml Labs, dan karena konflik nama dengan IDE Java Borland yang sudah ada, setelah diskusi komunitas namanya menjadi Dune
• Jane Street sempat mempertahankan Jenga dan Dune bersama-sama, tetapi ketika codebase membesar hingga 65 juta baris OCaml dan 5 juta baris Python, tingkat kesulitan migrasi internal meningkat tajam
• Setelah lebih dari setahun kerja intensif, codebase Jane Street kini dibuild dengan Dune, dan build yang sebagian besar cache-nya sudah terisi menjadi 2–3 kali lebih cepat

---

Jenga yang Berawal dari Ketidakpuasan terhadap OMake

• Sistem build adalah tool harian developer yang membuat program yang dapat dieksekusi dari banyak file sumber, sekaligus menangani pemanggilan compiler dan eksekusi test
• Sekitar 2012, Jane Street merasa tidak puas dengan OMake, salah satu sistem build standar OCaml saat itu, lalu membuat sistem build sendiri bernama Jenga
• Karena Jenga berjalan baik secara internal, Jane Street memutuskan untuk membukanya ke publik dengan anggapan komunitas juga dapat memanfaatkannya
  • Mereka berharap pengguna eksternal akan mencoba Jenga dan ikut berkontribusi
  • Mereka juga melihat ini akan mempermudah publikasi kode Jane Street sebagai open source
• Adopsi eksternal yang terjadi tidak sesuai harapan
  • Tidak berjalan di Windows
  • Untuk mengadopsi Jenga, pada praktiknya pengguna harus menerima seluruh cara Jane Street dalam membuild OCaml
• Ketika penggunaan eksternal tidak meningkat, Jane Street kembali menjadikan Jenga privat, sementara masalah build untuk kode open source tetap tersisa

Jbuilder yang Dibuat sebagai Lapisan Kompatibilitas

• Pada 2016, Jane Street memutuskan membuat Jbuilder, tool sederhana lintas platform yang memungkinkan pengguna eksternal membuild kode mereka tanpa harus menerima Jenga secara keseluruhan
• Tool ini juga bertujuan mengurangi beban untuk menulis ulang build agar sesuai dengan OCamlbuild, yang saat itu mulai muncul sebagai standar baru untuk membuild proyek OCaml
• Jbuilder memahami file jbuild yang digunakan Jenga untuk konfigurasi build, lalu menjalankan perintah kompilasi yang diperlukan dalam urutan topological sort
• Jbuilder awal masih jauh dari sistem build dalam pengertian umum
  • Tidak memilih hanya perintah yang inputnya berubah untuk dijalankan ulang
  • Setiap kali, semua perintah dijalankan ulang

Proses Jbuilder Berubah Menjadi Dune

• Jbuilder semula dimaksudkan sebagai lapisan kompatibilitas kecil, tetapi pengguna mulai memakainya bukan hanya untuk paket Jane Street, melainkan juga untuk membuild proyek mereka sendiri
• Faktor terbesar yang mendorong adopsi adalah kecepatan
  • Sekitar 5 kali lebih cepat dibanding OCamlbuild dalam kompilasi proyek Jane Street
  • Portabilitasnya baik
  • Strukturnya sederhana sehingga mudah dimodifikasi
• Jane Street bekerja sama dengan OCaml Labs, kini Tarides, untuk mulai mengembangkan Jbuilder menjadi sistem build yang lebih lengkap
• Nama menjadi masalah tersendiri
  • Sudah ada JBuilder, IDE Java dari Borland
  • Sistem tersebut pada dasarnya sudah lama menghilang, tetapi saat mereka menanyakan niat penggunaan nama kepada pemilik hak cipta, izin tidak diberikan
• Setelah diskusi komunitas, Dune dipilih sebagai nama baru
  • Diskusi terkait berlangsung di thread usulan nama baru untuk Jbuilder

Biaya Mempertahankan Dua Sistem Build Bersama-sama

• Seiring meningkatnya popularitas Dune, Jane Street harus mempertahankan dan mendukung dua sistem build lengkap yang mereka buat sendiri, Jenga dan Dune, secara bersamaan
• Dune memantapkan diri sebagai sistem dengan desain ulang, performa cepat pada sebagian besar build pengguna, adopsi lebih luas, serta API dan pengalaman pengguna yang lebih baik
• Kapan memindahkan internal ke Dune secara alami menjadi tugas berikutnya, tetapi tim sistem build sudah sibuk hanya untuk mengikuti pertumbuhan codebase
  • Saat Dune dimulai pada 2016, kode OCaml berjumlah 4 juta baris
  • Kini ada 65 juta baris OCaml dan 5 juta baris Python
• Migrasi ke Dune terlalu membebani untuk benar-benar dimulai, sehingga estimasi optimistis “mungkin bisa dilakukan dalam 6–12 bulan ke depan” terus berulang
• Tahun lalu, setelah memperbesar tim sistem build menjadi 5 engineer full-time, Jane Street memulai pekerjaan migrasi yang telah lama tertunda

Dune yang Menggantikan Jenga di Internal Jane Street

• Salah satu pekerjaan terbesar adalah membuat Dune dapat diskalakan sesuai codebase raksasa Jane Street
• Salah satu alasan Dune cepat di luar adalah karena sebagian besar pengguna membuild proyek yang jauh lebih kecil daripada repositori 70 juta baris milik Jane Street
• Jenga juga tidak berhenti begitu saja selama 10 tahun
  • Jane Street terus meningkatkan implementasi Jenga seiring pertumbuhan codebase
  • Jenga sudah cukup dioptimalkan untuk kebutuhan monorepo berskala besar
  • Sebagian besar pekerjaan optimisasi ini harus dipindahkan ke Dune
• Pekerjaan integrasi sehari-hari juga tidak mudah
  • Sistem build dipanggil dalam berbagai workflow
  • Tiga editor, Vim, Emacs, dan VSCode, masing-masing memiliki integrasi kustom untuk Jenga
  • Setiap integrasi harus dipindahkan satu per satu ke Dune
• Setelah lebih dari setahun kerja intensif, codebase Jane Street kini dibuild dengan Dune
  • Pada saat transisi, performa Dune secara keseluruhan sama atau lebih baik daripada Jenga
  • Dalam beberapa kasus, performanya jauh lebih baik
  • Ketika sebagian besar pekerjaan build sudah ada di cache, build menjadi 2–3 kali lebih cepat

Perbaikan Berikutnya yang Dimungkinkan di Atas Satu Sistem

• Jane Street berencana membuka sebagai open source sebagian besar peningkatan performa Dune, dan sebagian sudah dipublikasikan
• Agar tidak muncul kembali dua sistem, yaitu fork Dune untuk Jane Street dan Dune eksternal, mereka memperhatikan agar perubahan yang memungkinkan dimasukkan ke upstream
• Dune menjadi fondasi yang lebih cocok untuk membuat fitur baru
  • Codebase lebih sederhana dan lebih mudah dikerjakan
  • Mereka dapat fokus pada satu sistem
• Fitur-fitur berikut juga menjadi lebih dekat

  • Build terdistribusi

    • Build dangkal, yaitu “builds without the bytes”
    • Pemuatan cache untuk graph build itu sendiri
    • Tim sistem build telah berkembang menjadi 12 engineer full-time di New York, London, dan Singapura, dan laju peningkatan Dune juga meningkat

[GN⁺]

Komentar Hacker News

• Pesan crash Dune:

  Aku tidak akan menyebabkan segfault. Ketidakpastian adalah pembunuh pikiran. Exception adalah kematian kecil yang membawa kehancuran total. Aku akan mengekspresikan semua kasus secara lengkap. Eksekusi akan melewatiku dan menembusku. Setelah ia lewat, aku akan menggulung balik stack mengikuti jalurnya. Di tempat kasus-kasus telah ditangani, takkan ada apa-apa. Hanya aku yang akan tersisa

  • Wah, ternyata benar
    https://github.com/ocaml/dune/issues/2767
  • Rasanya seperti baru diinisiasi ke sesuatu

• Podcast teknologi Jane Street, Signals and Threads, punya episode tahun 2020 yang membahas build system, dan sangat saya rekomendasikan
  Episode lainnya juga bagus; khususnya The Future of Programming dengan Richard Eisenberg dan What is an Operating System? dengan Anil Madhavapeddy juga saya rekomendasikan
  ¥https://signalsandthreads.com/build-systems/
  °https://signalsandthreads.com/future-of-programming/
  §https://signalsandthreads.com/what-is-an-operating-system/

  • Cara penulisan catatan kaki ini menarik. Saya penasaran apakah itu sekadar demi kesenangan dan estetika, atau ada asal-usul atau tujuan yang lebih dalam
  • Rekomendasi yang bagus, dan Multicast and the Markets juga sangat bagus
    https://signalsandthreads.com/multicast-and-the-markets/

• Patut dihargai bahwa Jane Street membuktikan pemrograman fungsional bertipe HM juga bisa siap produksi dan sangat cepat jika diberi perhatian yang cukup
  Saya masih sesekali mendengar bahwa bahasa fungsional bergaya lebih akademis tidak bisa dipakai di produksi, tetapi OCaml menunjukkan bahwa itu sangat memungkinkan bahkan dengan kebutuhan performa tinggi

  • Mercury juga memakai Haskell di backend
    https://mercury.com/
  • Benar. F# juga cukup banyak dipakai di produksi
    Ini pilihan yang sangat baik untuk membuat program berkualitas tinggi sambil berinteroperasi luas dengan sistem yang sudah ada
  • NoRedInk juga memakai Haskell untuk sebagian backend, dan Elm untuk sebagian besar frontend
    Menurut tulisan blog beberapa tahun lalu, mereka juga pernah mencoba Roc, tetapi saya tidak tahu apakah masih dipakai sekarang
    [0] https://blog.noredink.com
  • pandoc juga ditulis dengan Haskell. Facebook juga pernah memakai Haskell untuk anti-spam, tetapi saya tidak tahu apakah masih begitu sekarang
  • Maksudnya sistem tipe memengaruhi kecepatan eksekusi? Setahu saya sistem tipe hanyalah analisis statis, jadi tidak berdampak pada kecepatan runtime

• Setiap kali membaca tulisan blog Janestreet, saya diam-diam tertawa karena bekerja di bidang finansial di Jane tampaknya lebih menarik dan lebih menguntungkan daripada 90% pekerjaan yang disebut industri teknologi

  • Jane Street dan beberapa perusahaan elite hanyalah sebagian sangat kecil dari tenaga teknologi di industri finansial
    Di pekerjaan teknologi sektor finansial, ada jauh lebih banyak pekerjaan yang tidak semenarik atau sebaik bayaran perusahaan teknologi rata-rata, apalagi Jane Street
  • Rumput tetangga memang selalu tampak lebih hijau
    Banyak pekerjaan di sektor finansial adalah memperbaiki kode Java berusia 20 tahun, atau mencari cara baru untuk memasukkan dan mengeluarkan data dari file Excel demi laporan khusus
  • Ini anekdot yang tidak bisa dibuktikan, tetapi seorang rekan pindah ke FAANG setelah bekerja 6 bulan di JS karena pekerjaannya terlalu membosankan. Padahal gajinya lebih tinggi
    Dan saya dengar masuk JS jauh lebih sulit daripada Google/Meta
    Saya juga pernah melamar dulu, dan pewawancaranya cukup tidak menyenangkan; saya tidak pernah mengalami hal seperti itu di wawancara big tech, jadi kesannya tidak bagus
  • Benarkah begitu? Jam kerjanya panjang, standarnya sangat ketat, dan pada akhirnya pekerjaannya memanipulasi angka demi laba, jadi bagi kebanyakan orang itu tidak terlalu bermakna
    Meski begitu, saya menilainya lebih tinggi daripada pekerjaan membuat orang mengklik iklan
  • Orang-orang terlalu melebih-lebihkan pekerjaan di Jane Street atau perusahaan high-frequency trading serupa yang sangat selektif
    Seperti perusahaan lain, ada campuran proyek menarik dan pekerjaan membosankan

• Satu-satunya hal yang lebih buruk daripada codebase yang kompleks adalah build system yang kompleks. CMake menjijikkan
  Jadinya seperti, “Untuk mengompilasi bahasa ini, pelajari satu bahasa baru lagi!”

  • Yang lebih buruk daripada build system kompleks adalah build system sederhana yang tidak bisa membangun apa yang dibutuhkan :(
  • Lebih tepatnya “pelajari bahasa baru yang payah ini”
  • Saya tidak membenci CMake. Memang mengerikan, tetapi karena kita sudah memakai C atau C++, standarnya sudah cukup rendah
    Ada beberapa hal yang dilakukannya dengan benar, dan sebagian hal yang dilakukannya salah masih bisa dikelola
    Jika satu set file konfigurasi yang bisa diedit manusia dapat memberi prosedur build untuk berbagai platform, saya bisa menanggung sebagian rasa sakitnya
  • Ide-ide dalam CMake modern yang berorientasi target itu bernilai
    Bahasa skripnya yang mengerikan memang menghambat, tetapi dengan motivasi yang cukup, itu bisa diperbaiki

• Dulu saya menghabiskan beberapa tahun di Haskell sebagai pengalaman fungsional pertama setelah Lisp
  OCaml tidak begitu terasa cocok, dan saya punya bentuk langka dari alergi titik koma, jadi Haskell jauh lebih enak dilihat
  Namun baru-baru ini saya mencoba Reason dan ternyata sangat bagus, lalu tiba-tiba semua hal terkait OCaml jadi menarik

  • F# tidak punya beberapa fitur OCaml yang lebih menarik, misalnya ekspresivitas sistem modul, tetapi karena sintaksnya sensitif terhadap indentasi, dalam kebanyakan kasus ia menyingkirkan banyak konstruksi, termasuk titik koma
    https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
  • “Jika tujuannya adalah mengompilasi atau menginterpretasikan file sebagai skrip, di OCaml titik koma ganda bisa dan sebaiknya dihindari. Jika dibiarkan pun tidak akan menimbulkan error, tetapi tidak ada gunanya. Compiler mengizinkannya agar saat menyalin-tempel dari UTop ke file, Anda tidak perlu menghapusnya.”
    https://ocaml.org/docs/toplevel-introduction#loading-librari...
    https://reasonml.github.io/ terlihat keren, seperti OCaml dengan nuansa JavaScript
  • Yang menarik, bagian yang selalu membuat saya enggan terhadap Haskell adalah rasanya seperti aliran whitespace dan identifier tanpa petunjuk visual untuk mengenali strukturnya
    Mungkin begitu memahami batas itu jadi baik-baik saja, tetapi sepertinya perlu belajar berpikir dengan struktur itu seperti Lisp. Tetap saja, kalau layar penuh kode Haskell, saya masih gentar
    Di antara semuanya, SML/NJ paling mudah dibaca
  • Saya berharap sintaks Reason menjadi sintaks default

• Saya penasaran apakah ada yang pernah memakai library dan tool OCaml open source dari Jane Street untuk proyek yang cukup serius
  Dari kesan sekilas, mereka memang mencurahkan banyak usaha untuk membangun ekosistem dan merilis kode sebagai open source, tetapi rasanya belum “siap” dipakai orang di luar Jane Street

  • Saya memakainya. Di proyek tempat saya pertama kali belajar OCaml, saya memakai pengganti standard library mereka, dan sejak itu terus menggunakannya
    Untuk menemukan sesuatu, Anda perlu cukup mahir membaca signature fungsi, tetapi selain itu tidak ada keluhan. Misalnya, fungsi untuk mengonversi ke dan dari s-expression untuk semua tipe dasar, kalau Anda tahu keberadaannya dan merencanakannya sejak awal, bisa sangat menghemat waktu
    Saya juga pernah memakai library lain, dan ppx untuk logging serta unit testing pada dasarnya mendekati standar de facto di dunia OCaml, kalau hal semacam itu memungkinkan di sana. Saya juga pernah memakai code formatter, satu test framework, dan implementasi struktur data tingkat lanjut
    Kadang, seperti komentar lain, saya juga menemui sesuatu yang benar-benar tidak berjalan. Misalnya bergantung pada sesuatu yang dirilis terpisah tetapi tidak terdokumentasi, atau butuh konfigurasi rahasia. Bukan karena niat buruk; sering kali kalau membuka issue lalu kembali 1–2 tahun kemudian, sudah berfungsi
    Bukan berarti tanpa frustrasi sama sekali, tetapi saya menghargai pendekatan mereka yang membuka semuanya, alih-alih memakai sumber daya untuk menguji dan memoles lebih sedikit rilis. Kualitas kodenya umumnya sangat tinggi, dan meski saya tidak berhasil menjalankannya sendiri, ia tetap menjadi contoh implementasi yang ketat dan teruji
  • Bukan proyek serius, tetapi saya memakai stdlib mereka untuk generator situs statis pribadi
    Menurut saya API-nya jauh lebih baik daripada stdlib standar
  • Saya mencoba memakai tool magic-trace, tetapi bahkan pada program dotnet sepele pun terjadi setidaknya 4 crash yang berbeda
  • Pernah memakainya di Bloomberg
  • Saya sedang menjalankan pengujian untuk proyek riset matematika yang kompleks, dan secara mengejutkan waktu eksekusinya sejauh ini berurutan Lean 4 << Haskell << OCaml
    Saya suka Lean 4, tetapi tidak mudah mendapatkan bantuan dari AI. Pekerjaan saya hari ini adalah mencerna manual referensi agar muat dengan baik di dalam context window 200K. Kita lihat nanti apakah membantu

• Cukup mengejutkan bahwa mengembangkan build system baru sendiri lalu bermigrasi ke sana masih masuk akal dibanding mengadopsi tool siap pakai seperti buck2 atau bazel
  Bukan berarti memperkenalkan build tool canggih seperti ini mudah, tetapi bagaimana jika dibandingkan dengan membuat sendiri? Saya penasaran apakah ada hal khusus yang membuat dune sangat berbeda

  • Detail spesifiknya mungkin bisa dijelaskan lebih baik oleh orang yang lebih berpengalaman, tetapi saat JS mulai membuat tool sendiri pada 2012, buck maupun bzl belum ada
    Rilis pertama Bazel pada 2015, Buck pada 2013
    JS memang punya sedikit budaya NIH, tetapi saya tidak tahu apakah itu berperan di sini. Saat itu belum banyak build tool yang bagus, terutama bagi perusahaan yang memakai tech stack tidak konvensional
  • Saya tidak terlalu paham OCaml secara khusus, tetapi pemahaman saya, dari yang disebutkan, satu-satunya build system yang benar-benar punya semantik untuk mengompilasi OCaml dengan benar adalah buck2
    Khususnya, seingat saya perlu bisa menjalankan ocamldep terlebih dahulu atau perlu mengompilasi dua kali; buck2 bisa melakukannya, sedangkan Bazel seingat saya butuh hack
  • Tim kami punya codebase OCaml besar dan sistem build ganda, yaitu buck2 dan dune
    Keduanya kurang lebih mirip. Untuk kecepatan murni memanggil tool build OCaml, dune lebih cepat; ketika harus membangun ulang banyak hal dan memakai sistem build terdistribusi, buck2 menang
    Sakit kepala besarnya adalah integrasi LSP. Karena satu-satunya cara server LSP mengetahui dependensi sebuah file adalah lewat build, ia harus terikat erat dengan build system. Di dune semuanya tersedia dengan rapi. Dengan buck2 kami juga berhasil merangkainya entah bagaimana, tetapi tidak sebagus itu

• Dune jelas nama terbaik untuk sebuah build system, tidak ada yang bahkan mendekati

  • Benar. “Dia yang menguasai build system menguasai semesta”
  • Mungkin karena software dibangun di atas pasir yang bergerak?

• Memulai untuk membuat build system yang lebih baik lalu “secara kebetulan” membuat build system yang lebih baik—aneh juga cara kebetulan seperti itu terjadi