Hydro: framework de programación distribuida para Rust

• Introducción

  • Hydro es un framework de programación distribuida de alto nivel para Rust.
  • Hydro ayuda a escribir rápidamente servicios distribuidos escalables y garantiza la seguridad distribuida, así como Rust garantiza la seguridad de memoria.
  • Permite ejecutar programas distribuidos fácilmente tanto en modo de prueba como en modo de despliegue.

• Características de Hydro

  • Hydro es un lenguaje de flujo de datos distribuido impulsado por un runtime DFIR monohilo de alto rendimiento.
  • A diferencia de las arquitecturas tradicionales como actores o RPC, ofrece una API coreográfica que permite describir cómputo a través de múltiples ubicaciones.
  • Está integrado con Hydro Deploy, por lo que se pueden desplegar y ejecutar fácilmente programas distribuidos de Hydro en local o en la nube.

• Compilación y despliegue

  • Hydro utiliza un enfoque de compilación de dos etapas.
  • Un programa de Hydro es un programa estándar de Rust que genera un plan de despliegue en la laptop del desarrollador.
  • Este plan se compila a DFIR para generar binarios individuales para cada máquina del sistema distribuido.
  • Se despliega en la nube usando el plan generado y las especificaciones de recursos en la nube.

• Casos de uso

  • Hydro se utiliza para implementar sistemas distribuidos de alto rendimiento como commit en dos fases y Paxos.
  • Se está desarrollando una biblioteca estándar de sistemas distribuidos que ofrece estos protocolos como componentes reutilizables.

• Precauciones

  • La documentación de Hydro todavía está en proceso, y si hay preguntas o errores, se recomienda abrir un issue en el repositorio de GitHub de Hydro.

[GN⁺]

Opiniones en Hacker News

• Hay una buena presentación en YouTube que explica el proyecto Hydro. Se enfoca principalmente en DFIR
  https://www.youtube.com/watch?v=YpMKUQKlak0&ab_channel=ACMSI...

• Parece que hacen falta más ejemplos de aplicación realistas para entender dónde convendría aplicarlo en la práctica

  • Aunque los ejemplos de código todavía no están completamente documentados, se puede ver una implementación más realista de Paxos aquí: https://github.com/hydro-project/hydro/blob/main/hydro_test/...
    También están trabajando en aplicaciones más complejas, como un almacén clave-valor

• Me pregunto si, al tener un lenguaje intermedio con su propio runtime en el medio, se pierden las ventajas que ofrece Rust
  Pensé que sería un lenguaje para coordinar binarios Rust separados y unirlos en un sistema distribuido coherente y funcional, pero parece que no es solo una capa de pegamento, sino que todo se escribe en DFIR de principio a fin

  • Soy uno de los estudiantes de doctorado que lidera el trabajo en Hydro. DFIR se parece más a un DSL de capa intermedia, y permite que quienes desarrollan en lenguajes de alto nivel reestructuren el código Rust para que sea más apto para optimizaciones de bajo nivel, como la vectorización
    Los operadores de DFIR (map, filter, etc.) reciben closures de Rust, por lo que pueden pasarse tal cual desde el lenguaje de alto nivel hasta el binario Rust final. Desde la perspectiva del usuario, no se interactúa directamente con DFIR
  • Si eso es lo que preguntas, DFIR está implementado en Rust

• Es realmente interesante. Si alguien conoce esta área, me gustaría saber si hubo trabajos previos o frameworks similares en otros lenguajes
  En el área de flujos de datos ha trabajado mucha gente; Materialize me pareció bastante genial y también usé Kafka Streams en el trabajo. Creo que un framework que unifique todo esto tendría sentido

  • A primera vista, conceptualmente se parece bastante a trabajos del área de ciencia de datos. Me vienen a la mente Spark o Dask, que también se mencionan en la documentación
    En particular, el hecho de estar basado en Rust y poder integrarse bien con otros lenguajes podría volverse una fortaleza. Spark eligió bien la JVM en términos de portabilidad, pero trae mucha complejidad; Dask corre en Python, así que si no estás ya usando Python, es una dependencia bastante pesada
    En cuanto a Rust distribuido, también vi Lunatic y me pareció bien, pero se veía algo más de bajo nivel que lo que apunta a ser Hydro
  • Parece una mezcla entre Akka (https://getakka.net/, con menos sensación enterprise que la versión Java), basado en el modelo de actores y enfocado en sistemas distribuidos, y bibliotecas reactivas como rx (https://reactivex.io/)
    Por eso, https://doc.akka.io/libraries/akka-core/current/stream/index... podría ser la comparación más cercana
  • Este proyecto salió de RISELab
    https://rise.cs.berkeley.edu/projects/
    La mayor parte del procesamiento de datos y los sistemas distribuidos tienen algún punto de conexión con la investigación que ha hecho este laboratorio

• Me gusta el esfuerzo, pero ojalá algún día llegue al ecosistema Rust algo como akka.rs

• Me pregunto cómo se compara con timely [0] desde la perspectiva de flujos de datos. También me interesa si la representación intermedia puede expresar flujo de control, como bucles
  [0] https://github.com/TimelyDataflow/timely-dataflow

  • Leí un poco el paper de Flo y parece describir grafos de flujo de datos como Timely, pero, a diferencia del trasfondo más centrado en la ejecución de Timely, parece venir de la tradición del flujo de datos semántico
    Está más cerca de la programación reactiva funcional, la composición, flujos de flujos, operadores algebraicos y un enfoque orientado a pruebas. Tiene un concepto de “progreso” muy distinto al de Timely y se centra en garantizar que la composición sea productiva incluso con entradas de streaming potencialmente infinitas
    De hecho, en Flo casi no hay concepto de “timeliness” ni timestamps. Soporta iteración anidada como Timely, pero el mecanismo es muy distinto. El álgebra básica es extremadamente acíclica, pero la formalización de streams/grafos anidados permite la iteración
    El paper también lo compara directamente con DBSP; según entiendo, DBSP también pertenece a la familia Timely/Naiad. Los autores consideran que Flo podría ser un marco semántico unificado para varios sistemas similares, como Flink, LVars y DBSP
    Así que los autores de Flo conocen bien Naiad/Timely y se inspiraron en sus grafos de iteración anidada, pero fuera de eso lo veo bastante diferente
  • El paper más reciente [0] menciona varias veces a Naiad (timely dataflow). Por ejemplo, dice: “Inspirados por los nodos ingress/egress de Naiad [34], los streams anidados pueden procesarse como grafos de flujo de datos anidados que procesan de forma iterativa fragmentos de datos provenientes de un stream más grande y permiten pasar estado entre iteraciones”
    [0] https://hydro.run/papers/flo.pdf

• Si cada “proceso” se despliega como un binario separado, supongo que significa que se ejecuta como un proceso independiente; en ese caso, parece problemático por el lado del aumento de overhead.
  Me da curiosidad cómo logran una comunicación rápida. ¿Usan algún mecanismo como IPC rápido con memoria compartida?
  Tampoco veo nada sobre la integración con async. Nos guste o no, la gran mayoría del código que maneja networking ya se pasó a async, y en muchas áreas que necesitan networking es difícil encontrar buenas bibliotecas que no sean asíncronas.

  • Yo entendí “distribuido” como que está dividido entre máquinas completamente separadas. Si es así, es necesario que cada componente se ejecute como un proceso independiente.
  • Actualmente Hydro está enfocado en aplicaciones de red, y la mayor parte del paralelismo no viene de dentro de una sola máquina, sino del paralelismo entre máquinas.
    Por eso, si se quiere paralelismo en una sola máquina, hay algo de overhead adicional. Como mencionas, es algo que definitivamente queremos resolver en el futuro mediante memoria compartida.
    La semana pasada, en POPL 2025, un estudiante de pregrado que participa en Hydro presentó un compilador que compila automáticamente bloques de código async-await a flujos de datos de Hydro. Todavía está en desarrollo y no está documentado, pero se puede ver aquí: https://github.com/hydro-project/HydraulicLift

• Se ve realmente genial y se me ocurren varias formas de usarlo. En particular, la parte de despliegue parece única.
  Espero que la documentación se complete más; en especial me interesan las partes de Streams, Singletons y Optionals, que parecen ser centrales.

  • Justo nos tocó semana de documentación :) Mientras tanto, el Rustdoc sobre streams está bastante completo: https://hydro.run/rustdoc/hydro_lang/stream/struct.Stream

• Me gusta el modelo de programación. Me da curiosidad si al reescribir la aplicación también realiza optimización de red.
  Quisiera saber si aborda los cuellos de botella de red o el manejo de congestión.

• Me pregunto cómo se compara con usar algo como Ballista para pipelines de datos.
  Ballista se beneficia mucho de estar construido sobre Apache Arrow y Apache Datafusion.

  • Soy una de las personas que crearon Hydro. El ecosistema alrededor de Ballista, Arrow y Parquet está mucho más enfocado en el procesamiento de consultas analíticas, mientras que Hydro busca llevar conceptos del mundo del procesamiento de consultas a la implementación de sistemas distribuidos.
    El objetivo no es ejecutar consultas SQL, sino tratar el código de sistemas distribuidos (por ejemplo, implementaciones de microservicios) como si fueran consultas SQL. La integración con Arrow y Parquet también está en el roadmap.