Hydro: Framework Pemrograman Terdistribusi untuk Rust

• Pengenalan

  • Hydro adalah framework pemrograman terdistribusi tingkat tinggi untuk Rust.
  • Hydro membantu menulis layanan terdistribusi yang dapat diskalakan dengan cepat, dan menjamin keamanan terdistribusi sebagaimana Rust menjamin keamanan memori.
  • Mendukung agar program terdistribusi dapat dijalankan dengan mudah dalam mode pengujian maupun mode deployment.

• Fitur Hydro

  • Hydro adalah bahasa aliran data terdistribusi yang berjalan di atas runtime DFIR single-thread berperforma tinggi.
  • Berbeda dari arsitektur tradisional seperti actor atau RPC, Hydro menyediakan API choreographic yang dapat mendeskripsikan komputasi lintas banyak lokasi.
  • Terintegrasi dengan Hydro Deploy sehingga program Hydro terdistribusi dapat dengan mudah di-deploy dan dijalankan secara lokal maupun di cloud.

• Kompilasi dan deployment

  • Hydro menggunakan pendekatan kompilasi dua tahap.
  • Program Hydro adalah program Rust standar yang menghasilkan deployment plan di laptop pengembang.
  • Rencana ini dikompilasi menjadi DFIR untuk menghasilkan biner terpisah bagi setiap mesin dalam sistem terdistribusi.
  • Dengan menggunakan rencana yang dihasilkan dan spesifikasi resource cloud, program kemudian di-deploy ke cloud.

• Kasus penggunaan

  • Hydro digunakan untuk mengimplementasikan sistem terdistribusi berperforma tinggi seperti two-phase commit dan Paxos.
  • Sedang dikembangkan pustaka standar sistem terdistribusi yang menyediakan protokol-protokol ini sebagai komponen yang dapat digunakan kembali.

• Hal yang perlu diperhatikan

  • Dokumentasi Hydro masih dalam proses pengerjaan, dan jika ada pertanyaan atau bug, pengguna disarankan untuk membuka issue di repositori GitHub Hydro.

[GN⁺]

Pendapat Hacker News

• Ada presentasi YouTube yang bagus yang menjelaskan proyek Hydro. Sebagian besar berfokus pada DFIR
  https://www.youtube.com/watch?v=YpMKUQKlak0&ab_channel=ACMSI...

• Sepertinya masih perlu lebih banyak contoh penerapan realistis untuk memahami di mana ini sebaiknya diterapkan dalam praktik

  • Contoh kode memang belum sepenuhnya terdokumentasi, tetapi implementasi Paxos yang lebih realistis bisa dilihat di sini: https://github.com/hydro-project/hydro/blob/main/hydro_test/...
    Mereka juga sedang membuat aplikasi yang lebih kompleks seperti penyimpanan key-value

• Saya penasaran, jika ada bahasa perantara dengan runtime sendiri di tengah, apakah keunggulan yang diberikan Rust jadi hilang
  Saya kira ini adalah bahasa untuk mengorkestrasi beberapa binary Rust terpisah agar menjadi sistem terdistribusi yang konsisten dan berfungsi, tetapi sepertinya bukan sekadar lapisan perekat, melainkan ditulis dengan DFIR dari awal sampai akhir

  • Saya salah satu mahasiswa doktoral yang memimpin pekerjaan Hydro. DFIR lebih mirip DSL lapisan menengah, dan memungkinkan developer bahasa tingkat tinggi menyusun ulang kode Rust agar lebih cocok untuk optimisasi tingkat rendah seperti vectorization
    Operator DFIR (map, filter, dan sebagainya) menerima closure Rust, sehingga bisa diteruskan apa adanya dari bahasa tingkat tinggi hingga binary Rust akhir. Dari sudut pandang pengguna, mereka tidak akan berurusan langsung dengan DFIR
  • Kalau itu yang ditanyakan, DFIR diimplementasikan dengan Rust

• Benar-benar menarik. Kalau ada yang paham bidang ini, saya ingin tahu apakah ada riset terdahulu atau framework serupa di bahasa lain
  Di sisi dataflow, sudah banyak orang mengerjakannya dan saya menganggap Materialize cukup keren; saya juga pernah memakai Kafka Streams di pekerjaan. Rasanya framework yang merangkai semua ini akan masuk akal

  • Saat pertama melihatnya, secara konsep ini tampak cukup mirip dengan pekerjaan di bidang data science. Saya teringat Spark atau Dask yang juga disebutkan di dokumentasinya
    Terutama karena berbasis Rust, ada kemungkinan ini menjadi kuat berkat kemampuannya berpadu baik dengan bahasa lain. Untuk portabilitas, JVM adalah pilihan yang bagus bagi Spark, tetapi membawa banyak kompleksitas; Dask berjalan di Python, sehingga menjadi dependensi yang cukup berat kecuali jika memang sudah memakai Python
    Untuk Rust terdistribusi, saya juga pernah melihat Lunatic dan tampaknya lumayan, tetapi terlihat lebih low-level dibanding arah yang dituju Hydro
  • Ini terlihat seperti campuran Akka (https://getakka.net/, lebih tidak terasa enterprise dibanding versi Java-nya), yang berbasis actor model dan berfokus pada sistem terdistribusi, dengan library reactive seperti rx (https://reactivex.io/)
    Jadi https://doc.akka.io/libraries/akka-core/current/stream/index... mungkin menjadi pembanding terdekat
  • Proyek ini berasal dari RISELab
    https://rise.cs.berkeley.edu/projects/
    Sebagian besar pemrosesan data dan sistem terdistribusi punya keterkaitan tertentu dengan riset yang telah dilakukan lab ini

• Saya menyukai upayanya, tetapi semoga suatu hari ada sesuatu seperti akka.rs yang masuk ke ekosistem Rust

• Saya penasaran bagaimana perbandingannya dengan timely [0] dari sudut pandang dataflow. Saya juga penasaran apakah control flow seperti loop dapat direpresentasikan dalam intermediate representation
  [0] https://github.com/TimelyDataflow/timely-dataflow

  • Saya sempat membaca sedikit paper Flo; tampaknya ia mendeskripsikan graf dataflow seperti Timely, tetapi berbeda dari latar belakang Timely yang lebih berorientasi eksekusi, Flo tampaknya berasal dari tradisi dataflow semantik
    Lebih dekat ke functional reactive programming, composition, flow of flows, operator aljabar, dan pendekatan berorientasi pembuktian. Flo memiliki konsep “progress” yang sangat berbeda dari Timely, dan berfokus untuk memastikan composition tetap generative bahkan pada input streaming yang secara potensial tak terbatas
    Sebenarnya di Flo hampir tidak ada konsep “timeliness” dan tidak ada timestamp. Flo mendukung iterasi bersarang seperti Timely, tetapi mekanismenya sangat berbeda. Aljabar dasarnya sangat acyclic, tetapi formalisasi stream/graf bersarang memungkinkan iterasi
    Paper tersebut juga membandingkannya langsung dengan DBSP; sejauh pemahaman saya, DBSP juga berada dalam garis keturunan Timely/Naiad. Para penulis melihat Flo dapat menjadi framework semantik terpadu untuk berbagai sistem serupa seperti Flink, LVars, dan DBSP
    Jadi menurut saya para penulis Flo mengenal Naiad/Timely dengan baik dan terinspirasi oleh graf iterasi bersarangnya, tetapi selain itu cukup berbeda
  • Paper terbaru [0] beberapa kali menyebut Naiad (timely dataflow). Misalnya, “Terinspirasi oleh node ingress/egress di Naiad [34], stream bersarang dapat diproses oleh graf dataflow bersarang yang berulang kali memproses potongan data dari stream yang lebih besar dan mendukung penerusan state antar-iterasi”
    [0] https://hydro.run/papers/flo.pdf

• Jika setiap “proses” didistribusikan sebagai binary terpisah, mungkin maksudnya dijalankan sebagai proses terpisah juga; kalau begitu, dari sisi overhead yang meningkat sepertinya ada masalah
  Saya penasaran bagaimana komunikasi cepat dicapai. Apakah memakai mekanisme seperti shared-memory IPC yang cepat?
  Selain itu, saya juga tidak melihat pembahasan tentang integrasi dengan async. Suka atau tidak, mayoritas besar kode yang menangani networking sudah beralih ke async, dan di banyak area yang membutuhkan networking, sulit menemukan library bagus yang tidak asynchronous

  • Saya memahami “terdistribusi” sebagai berarti benar-benar dibagi ke mesin yang terpisah. Jika demikian, tiap komponen memang perlu berjalan sebagai proses independen
  • Saat ini Hydro berfokus pada aplikasi jaringan, dan sebagian besar paralelismenya berasal dari paralelisme antarmesin, bukan di dalam satu mesin
    Jadi jika menginginkan paralelisme pada satu mesin, memang ada sedikit overhead tambahan. Seperti yang disebutkan, ini adalah bagian yang sangat ingin kami selesaikan ke depannya melalui shared memory
    Pekan lalu di POPL 2025, seorang mahasiswa S1 yang berkontribusi pada Hydro mempresentasikan compiler yang secara otomatis mengompilasi blok kode async-await menjadi aliran data Hydro. Masih dalam proses pengerjaan dan belum didokumentasikan, tetapi bisa dilihat di sini: https://github.com/hydro-project/HydraulicLift

• Ini terlihat sangat keren dan saya bisa membayangkan beberapa cara penggunaannya. Terutama bagian deployment-nya tampak unik
  Saya menantikan dokumentasinya lebih lengkap, dan khususnya penasaran dengan bagian Streams, Singletons, dan Optionals yang tampaknya menjadi inti

  • Kebetulan memang sedang masuk minggu penulisan dokumentasi :) Untuk sementara, Rustdoc untuk stream sudah cukup lengkap: https://hydro.run/rustdoc/hydro_lang/stream/struct.Stream

• Saya suka model pemrogramannya. Saya penasaran apakah saat menulis ulang aplikasi, ia juga melakukan optimisasi jaringan
  Saya ingin tahu apakah ia menangani bottleneck jaringan atau congestion handling

• Saya penasaran bagaimana perbandingannya dengan memakai sesuatu seperti Ballista untuk data pipeline
  Ballista banyak diuntungkan karena dibangun di atas Apache Arrow dan Apache Datafusion

  • Saya salah satu pembuat Hydro. Ekosistem di sekitar Ballista, Arrow, dan Parquet jauh lebih berfokus pada pemrosesan query analitik, sementara Hydro mencoba membawa konsep dari dunia pemrosesan query ke implementasi sistem terdistribusi
    Tujuannya bukan menjalankan query SQL, melainkan memperlakukan kode sistem terdistribusi (misalnya implementasi microservice) seperti query SQL. Integrasi Arrow dan Parquet juga masuk dalam roadmap