Hydro: Ein Framework für verteilte Programmierung in Rust

• Einführung

  • Hydro ist ein High-Level-Framework für verteilte Programmierung in Rust.
  • Hydro hilft dabei, skalierbare verteilte Services schnell zu schreiben, und garantiert verteilte Sicherheit, so wie Rust Speichersicherheit garantiert.
  • Es unterstützt die einfache Ausführung verteilter Programme im Testmodus oder im Deployment-Modus.

• Eigenschaften von Hydro

  • Hydro ist eine verteilte Dataflow-Sprache, die von einer performanten Single-Thread-DFIR-Runtime angetrieben wird.
  • Anders als traditionelle Architekturen wie Actor oder RPC bietet es eine choreografische API, mit der sich Berechnungen über mehrere Orte hinweg beschreiben lassen.
  • Durch die Integration mit Hydro Deploy lassen sich verteilte Hydro-Programme lokal oder in der Cloud einfach bereitstellen und ausführen.

• Kompilierung und Deployment

  • Hydro verwendet einen zweistufigen Kompilierungsansatz.
  • Hydro-Programme sind Standard-Rust-Programme, die auf dem Laptop des Entwicklers einen Deployment-Plan erzeugen.
  • Dieser Plan wird zu DFIR kompiliert und erzeugt einzelne Binärdateien für jede Maschine im verteilten System.
  • Mit dem erzeugten Plan und den Spezifikationen der Cloud-Ressourcen wird anschließend in die Cloud deployt.

• Anwendungsfälle

  • Hydro wird zur Implementierung hochperformanter verteilter Systeme wie Two-Phase Commit und Paxos verwendet.
  • Derzeit wird an einer Standardbibliothek für verteilte Systeme gearbeitet, die diese Protokolle als wiederverwendbare Komponenten bereitstellt.

• Hinweise

  • Die Dokumentation von Hydro ist noch in Arbeit; bei Fragen oder Bugs wird empfohlen, im Hydro-GitHub-Repository ein Issue zu eröffnen.

[GN⁺]

Hacker-News-Kommentare

• Es gibt auf YouTube einen guten Vortrag über das Hydro-Projekt
  • Der Schwerpunkt liegt auf DFIR
• Ein praktisches Anwendungsbeispiel würde beim Verständnis helfen
• Ich frage mich, ob man die Vorteile von Rust verliert, wenn es eine Zwischensprache und eine eigene Runtime gibt
  • Ich hatte eine Sprache erwartet, die Rust-Binärdateien zu einem konsistenten und funktionalen verteilten System orchestriert, aber es scheint eher so zu sein, als würde man DFIR schreiben
• Das Projekt ist wirklich interessant
  • Ich frage mich, ob jemand mit Erfahrung in diesem Bereich frühere Beispiele nennen kann
  • Ich frage mich, ob es Leute gibt, die ähnliche Frameworks in anderen Sprachen gebaut haben
  • Es gibt Leute, die an Dataflow gearbeitet haben, und ich fand Materialize sehr cool
  • Ich habe Kafka Streams verwendet und dachte, dass ein Framework nötig wäre, das dies integriert
• Der Aufwand ist gut, aber ich hoffe, dass „akka.rs“ ins Rust-Ökosystem kommt
• Ich frage mich, wie es sich aus Dataflow-Sicht im Vergleich zu Timely verhält
  • Ich frage mich, ob sich Kontrollfluss wie Schleifen im IR ausdrücken lässt
• Ich frage mich, ob jeder „Prozess“ als separate Binärdatei bereitgestellt und als eigener Prozess ausgeführt wird
  • Falls ja, scheint es das Problem zu geben, dass der Overhead steigt
  • Ich frage mich, wie schnelle Kommunikation erreicht wird
  • Ich frage mich, ob es einen schnellen Shared-Memory-IPC-Mechanismus gibt
  • Es scheint keine Erwähnung der Integration mit Async zu geben
  • Der meiste Code, der sich mit Networking befasst, ist auf Async umgestellt worden
  • Es ist schwer, gute Async-Bibliotheken für viele Dinge zu finden, die Networking benötigen
• Es sieht wirklich cool aus, besonders der Deployment-Teil wirkt einzigartig
  • Ich hoffe auf ausführlichere Dokumentation
  • Mich interessieren besonders die offenbar wichtigen Teile Streams, Singletons und Optionals
• Mir gefällt das Programmiermodell
  • Ich frage mich, ob beim Umschreiben der Anwendung Netzwerkoptimierungen durchgeführt werden
  • Ich frage mich, wie Netzwerkengpässe und Überlastung behandelt werden
• Ich frage mich, wie es im Vergleich dazu ist, Ballista für Datenpipelines zu verwenden
  • Letzteres ist auf Apache Arrow und Apache Datafusion aufgebaut und profitiert dadurch von vielen Vorteilen