1 poin oleh GN⁺ 2025-06-15 | 1 komentar | Bagikan ke WhatsApp
  • OxCaml adalah kumpulan ekstensi yang menambahkan fitur berorientasi performa ke OCaml
  • Berfungsi sebagai kompiler produksi Jane Street sekaligus laboratorium fitur masa depan untuk OCaml
  • Menekankan keamanan, kemudahan, dan prediktabilitas untuk memperluas kendali atas performa
  • Menyediakan fitur di berbagai area seperti fearless concurrency, kontrol layout, dan kontrol alokasi
  • Tersedia sebagai open source sehingga pengguna eksperimental dan peneliti dapat bebas menguji dan memberikan masukan

Pengenalan OxCaml

Apa itu OxCaml

  • OxCaml adalah sekumpulan ekstensi yang berkembang cepat untuk bahasa pemrograman OCaml
  • Ini merupakan kompiler siap pakai untuk kebutuhan produksi milik Jane Street, sekaligus platform eksperimental untuk memperkuat pemrograman yang berfokus pada performa di OCaml
  • Tujuannya adalah berkontribusi pada fitur-fitur ekstensi ini ke OCaml resmi dalam jangka panjang

Tujuan desain utama OxCaml

  • Bertujuan menyediakan lingkungan untuk mengendalikan faktor-faktor penentu performa dalam perilaku program secara aman, mudah, dan dapat diprediksi
  • Kendali ini hanya disediakan secara opsional saat benar-benar diperlukan
  • Semuanya diimplementasikan di dalam ekosistem OCaml

Pendekatan desain yang konkret

  • Keamanan: memperkuat keamanan bahasa untuk menjamin produktivitas programmer dan ketepatan kode. Bahasa yang terlalu luas dengan banyak bagian tidak aman sulit digunakan

  • Kemudahan: memberi kendali tanpa menambah kompleksitas pemrograman, sambil tetap mempertahankan keuntungan inferensi tipe

  • Prediktabilitas: menampilkan karakteristik performa inti secara eksplisit di tingkat sistem tipe, sehingga lebih mudah menalar performa kode

  • Ekstensi-ekstensi ini menggunakan pendekatan pay-as-you-go, yaitu hanya diterapkan pada bagian yang membutuhkannya. Artinya, jika tidak menggunakan fitur ekstensi, Anda tetap bisa mempertahankan kesederhanaan dan pola OCaml yang ada

  • OxCaml kompatibel dengan semua program OCaml dan secara internal mengarah pada evolusi OCaml. Ia mempertahankan keamanan, kemudahan penggunaan, dan produktivitas yang dimiliki OCaml saat ini

Pengenalan fitur ekstensi OxCaml

Fearless concurrency

  • Untuk mengatasi sulitnya pemrograman konkurensi yang benar, OxCaml memperluas sistem tipe untuk mencegah data race secara statis

Layouts

  • Programmer dapat menentukan layout data di memori secara eksplisit
  • Juga menyediakan akses native ke ekstensi prosesor SIMD pada perangkat keras modern

Kontrol alokasi

  • Menyediakan alat untuk mengendalikan alokasi memori secara rinci, sehingga mengurangi beban garbage collection (GC) dan meningkatkan efisiensi cache serta determinisme program

Peningkatan kualitas hidup

  • Selain untuk pemrograman sistem, juga menyediakan fitur-fitur yang terbukti membantu dalam pekerjaan sehari-hari

    • Polymorphic parameters
    • Include functor
    • Labeled tuples
    • Immutable arrays

Pemanfaatan dan penerapan OxCaml

  • OxCaml dirilis sebagai open source, sehingga peneliti, pengguna eksperimental, dan pengembang dapat berkontribusi melalui pengujian dan umpan balik

  • Namun, fitur ekstensi OxCaml tidak menjamin stabilitas maupun kompatibilitas mundur (meski kompatibilitas mundur untuk program OCaml yang ada tetap dijamin)

  • Disediakan versi alat-alat standar OCaml yang telah disesuaikan untuk OxCaml

    • Manajemen paket: kompatibel dengan dune dan opam
    • Integrasi editor: mendukung LSP-server
    • Pemformatan kode sumber dan pembuatan dokumentasi tersedia
  • Berbagai pustaka dan alat yang dirilis oleh Jane Street disediakan dalam dua bentuk

    • Untuk Upstream OCaml: versi dengan ekstensi OxCaml dihapus
    • Khusus OxCaml: versi yang memanfaatkan fitur ekstensi
  • Sebagian fitur ekstensi tidak dapat dihapus, sehingga pustaka terkait hanya dapat digunakan di OxCaml. Jika ekstensi yang diperlukan nanti diintegrasikan ke OCaml resmi, versi yang kompatibel dengan OCaml juga akan dirilis

1 komentar

 
GN⁺ 2025-06-15
Opini Hacker News
  • Terkait proyek yang dibuat tim Jane Street ini, saya ingin memperkenalkan bahwa ada diskusi menarik di episode podcast yang menampilkan mereka tentang pertimbangan performa saat bekerja dengan OCaml
    Kekhawatiran tentang penerapan bahasa GC di lingkungan latensi sangat rendah terus berlanjut
    Misalnya, jika GC pause terjadi di tengah high-frequency trading, situasinya bisa menjadi masalah serius
    Membagikan tautan podcast

    • Membagikan pengalaman pernah bertanya langsung kepada Ron Minsky di Twitter tentang alasan tidak memakai Rust untuk aplikasi latensi rendah
      Dari jawaban Ron, sambil mengakui Rust itu hebat, fokusnya ada pada nilai menjaga seluruh kode tetap dalam satu bahasa
      Tipe, tool, library, idiom, dan hal-hal lain bisa dibagi pakai, serta perpindahan antarproyek menjadi lebih mudah
      Juga disebutkan bahwa OCaml sedang berkembang agar dapat mengintegrasikan keunggulan utama Rust dengan baik secara internal sehingga bisa dimanfaatkan secara bertahap
      Kekurangan Rust yang disebut antara lain waktu kompilasi yang lama, sistem tipe yang kompleks, serta keluhan soal penanganan async/await
      Yang paling ditekankan adalah keinginan akan satu tool bahasa yang cocok untuk lingkungan kerja yang luas
      Membagikan tautan tweet tersebut

    • Ditekankan bahwa inti masalahnya bukan bahasa GC itu sendiri, melainkan sudut pandang yang memperlakukan semua bahasa GC sebagai satu kategori yang sama
      Masalah yang benar-benar penting adalah ketika bahasa GC tidak mendukung manipulasi eksplisit stack dan value type
      Jika menginginkan produktivitas bahasa GC sekaligus opsi yang rinci untuk coding level sistem, disebutkan alternatif seperti Cedar, keluarga Oberon, Modula-3, D, Nim, Eiffel, C#, F#, Swift, dan Go

    • Sebagai pembahasan umum tentang runtime yang memakai GC, disebutkan bahwa untuk meminimalkan GC pause, kita bisa memanfaatkan algoritma koleksi paralel JVM dan sebagainya
      Namun, metode ini tidak memberi jaminan yang seragam, sehingga ada situasi yang juga memerlukan overprovisioning RAM sistem
      Lebih jauh lagi, ada juga cara dengan sengaja meng-overprovision server agar sebagian server bisa sementara keluar dari pool untuk menangani "offline GC"
      Pendekatan seperti ini memerlukan kerja sama antara request router dan server, sehingga hanya bermakna bila ada anggaran yang cukup untuk ekspansi server
      Penjelasan parallel GC JVM

    • Dibagikan pengalaman bahwa banyak sistem kesulitan karena isu kompaksi GC
      Dalam sistem trading, umumnya ada kebijakan untuk meminimalkan alokasi setelah startup
      Di JS ada library bernama "Zero" yang menyediakan utilitas dengan pendekatan non-alokasi

    • Belum mengecek tautannya, tetapi ada pendapat bahwa di lingkungan seperti trading yang memiliki jam buka dan tutup pasar, mungkin saja GC dinonaktifkan selama jam perdagangan lalu proses di-restart setelah pasar tutup

  • Saya ingin menekankan bahwa fitur pertama dari fork ini yang masuk ke upstream adalah labeled tuple
    Dijadwalkan didukung di OCaml 5.4
    Tautan PR upstream
    Tautan diskusi terkait

    • Meski fitur ini tampak agak sepele, antusiasmenya ternyata cukup besar
      Saya juga ingin menambahkan informasi tentang paper dan video presentasi penulis fitur ini di ML2024
      Video YouTube
      PDF paper

    • Sebagai contoh labeled tuple, ini bisa mencegah kesalahan urutan pada pasangan, tetapi secara pribadi ada pendapat bahwa anonymous record di F# lebih disukai
      Misalnya, dengan {| product = 6; sum = 5 |}, urutan field tidak punya arti sehingga tidak terjadi kekeliruan

    • Immutable array juga digabungkan ke 5.4 dari fork ini, hanya sintaksnya sedikit berbeda

    • Ditekankan bahwa anonymous labeled struct dan enum adalah fitur papan atas yang diinginkan dalam bahasa pemrograman
      Sebagai contoh, di Rust kita bisa mendefinisikan struct berlabel maupun tanpa label
      Namun ada kekecewaan karena anonymous labeled struct tidak bisa dipakai untuk tipe kembalian fungsi

      struct Foo(i32, i32);
      struct Bar{sum: i32, product: i32}
      fn can() -> (i32, i32)
      fn cant() -> {sum: i32, product: i32}
      
  • Saya tidak tahu bahwa fork ini mendukung SIMD
    Disebutkan bahwa jika unboxed type, alokasi stack eksplisit, dan dukungan Windows juga tersedia, maka secara pribadi OxCaml bisa menjadi cukup layak dipakai alih-alih F# di lingkungan konsumen seperti game dev

    • Saat ini 128-bit SSE/NEON sudah berjalan dan AVX juga akan segera didukung
      Dukungan Windows bukan benar-benar terblokir, tetapi memerlukan sedikit pekerjaan
      Secara pribadi saya ingin menyoroti bahwa OxCaml sudah menambahkan dukungan SIMD
  • Dibagikan tips pengaturan environment variable bagi mereka yang memakai opam switch baru
    env OCAMLPARAM="alert=-unsafe_multidomain,_," opam install cohttp-lwt-unix
    Saat alert dipromosikan menjadi error, ada masalah instalasi paket lama yang jadi gagal tanpa perlu
    Dengan menonaktifkan alert tersebut lewat environment variable OCAMLPARAM, masalah instalasi bisa dicegah

  • Karena terbiasa dengan plugin vscode yang hebat untuk Golang, ada yang penasaran apakah lingkungan OCaml juga punya rencana integrasi dengan vscode
    Integrasi dengan vscode membuat setup menjadi sangat mudah

    • Plugin vscode untuk OCaml sendiri sudah banyak mendukung integrasi sintaks baru seperti dune, menhir, dan reason
      Jika OxCaml makin populer, tentu ada kemungkinan integrasinya ikut berkembang
      Secara pribadi saya memakai emacs jadi sulit bicara detail, tetapi alurnya terasa wajar
  • Saya ingin menyebut versi mikro dari OcaML
    Tautan proyek mlite

  • Ada pertanyaan apakah tujuan proyek ini dipublikasikan mungkin agar LLM bisa mengindeks informasinya lalu memanfaatkannya untuk model terbuka

    • Karena bahkan untuk OCaml biasa saja kemampuan LLM masih sangat kurang dan jumlah datanya sedikit, dinilai sama sekali tidak mungkin itu alasannya untuk OxCaml yang materinya lebih minim lagi
      Untuk tujuan seperti ini, membuat MCP dokumentasi sendiri akan jauh lebih bermakna

    • Karena nilainya sebagai sinyal tidak cukup, praktis ini tidak terlalu berarti
      Misalnya, bahkan untuk penyelesaian Gleam pun performa LLM sangat rendah, dan tetap gagal meski diberi pola yang jelas serta panduan kesalahan
      Karena itu sinyalnya terlalu lemah bila tujuannya adalah menyediakan informasi OxCaml

  • Menarik untuk diamati bahwa OxCaml adalah perluasan dari sebuah dialek dalam keluarga ML
    Ada antusiasme terhadap seperti apa langkah berikutnya nanti

    • Pernah bertanya-tanya siapa yang lebih bermasalah: orang yang terus menambahkan fitur ke bahasa yang sudah ada, atau orang yang sejak awal membuat bahasa baru
      Saya sendiri termasuk yang kedua, tetapi saya merasa programmer punya sifat genetik untuk tidak bisa membiarkan tool tetap apa adanya

    • Ada ajakan bercanda apakah F# juga bisa sekalian diperkenalkan

  • Diklarifikasi bahwa alasan proyek ini memakai nama "oxidized" adalah karena target fiturnya terkait Rust, seperti fearless concurrency dan penghindaran GC, bukan karena benar-benar memakai Rust
    Disebutkan bahwa penamaannya memang agak membingungkan

    • Ada ironi kecil bahwa nama Rust sendiri sebenarnya berasal dari jamur "rust", bukan dari karat

    • Dibagikan fakta bahwa Jane Street sudah lama menjalankan seri blog berjudul 'Oxidizing OCaml'

    • Istilah itu juga dipakai dalam judul paper "Oxidizing OCaml with Modal Memory Management", dan di dalam paper tersebut kata 'oxidize' tidak pernah didefinisikan atau dirujuk secara eksplisit
      Kesan yang muncul: aneh, tetapi cukup mudah melekat di ingatan

    • Diperkirakan bahwa dari sisi Rust, integrasi dengan custom tracing GC—yang tetap bisa mengejar performa maksimal sambil menangani struktur graf umum—akan lebih praktis dipakai sampai proyek ini mencapai kesetaraan fitur dengan Rust
      Jika tidak, ini hanya terasa seperti dipertahankan karena sudah ada banyak codebase terkait OxCaml