Hydro : framework de programmation distribuée pour Rust

 (hydro.run)
1 points par GN⁺ 2025-02-02 | 1 commentaires | Partager sur WhatsApp

  • Introduction

    • Hydro est un framework de programmation distribuée de haut niveau pour Rust.
    • Hydro aide à écrire rapidement des services distribués extensibles et garantit la sûreté distribuée, tout comme Rust garantit la sûreté mémoire.
    • Il permet d’exécuter facilement des programmes distribués en mode test ou en mode déploiement.

  • Caractéristiques de Hydro

    • Hydro est un langage de flux de données distribué, exécuté par le runtime DFIR monothread haute performance.
    • Contrairement aux architectures traditionnelles comme les acteurs ou les RPC, il fournit une API chorégraphique permettant de décrire des calculs répartis sur plusieurs emplacements.
    • Intégré à Hydro Deploy, il permet de déployer et d’exécuter facilement des programmes Hydro distribués en local ou dans le cloud.

  • Compilation et déploiement

    • Hydro utilise une approche de compilation en deux étapes.
    • Un programme Hydro est un programme Rust standard qui génère un plan de déploiement depuis l’ordinateur portable du développeur.
    • Ce plan est compilé en DFIR afin de produire des binaires distincts pour chaque machine du système distribué.
    • Le déploiement dans le cloud s’effectue à l’aide du plan généré et des spécifications des ressources cloud.

  • Cas d’usage

    • Hydro est utilisé pour implémenter des systèmes distribués haute performance comme le commit en deux phases et Paxos.
    • Une bibliothèque standard pour les systèmes distribués, fournissant ces protocoles sous forme de composants réutilisables, est en cours de développement.

  • Remarques

    • La documentation de Hydro est encore en cours de rédaction ; en cas de question ou de bug, il est recommandé d’ouvrir une issue sur le dépôt GitHub de Hydro.

À lire aussi

1 commentaires

 
GN⁺ 2025-02-02
Avis Hacker News
  • Il y a une bonne conférence sur le projet Hydro sur YouTube
    • Elle est centrée sur le DFIR
  • Un cas d’usage concret aiderait sans doute à mieux comprendre
  • Je me demande si l’existence d’un langage intermédiaire et d’un runtime dédié ne fait pas perdre les avantages de Rust
    • Je m’attendais à un langage qui orchestre des binaires Rust en système distribué cohérent et fonctionnel, mais cela ressemble plutôt à l’écriture de DFIR
  • Ce projet est vraiment intéressant
    • Je me demande si quelqu’un qui connaît bien ce domaine peut citer des précédents
    • Je me demande si des gens ont construit des frameworks similaires dans d’autres langages
    • Il y a des gens qui ont travaillé sur le dataflow, et j’ai trouvé Materialize très cool
    • J’ai de l’expérience avec Kafka Streams et j’ai pensé qu’il fallait un framework pour unifier tout cela
  • L’effort est appréciable, mais j’aimerais voir un "akka.rs" arriver dans l’écosystème Rust
  • Je me demande comment cela se compare à Timely du point de vue du dataflow
    • Je me demande si l’IR peut exprimer des flux de contrôle comme des boucles
  • Je me demande si chaque « processus » est déployé comme un binaire distinct et exécuté comme un processus séparé
    • Si c’est le cas, il semble y avoir un problème de surcoût accru
    • Je me demande comment les communications rapides sont réalisées
    • Je me demande s’il existe un mécanisme IPC rapide en mémoire partagée
    • Il ne semble pas y avoir de mention de l’intégration avec l’asynchrone
    • La majeure partie du code qui gère le réseau est passée à l’asynchrone
    • Il est difficile de trouver de bonnes bibliothèques asynchrones pour beaucoup de choses nécessitant du réseau
  • Cela a l’air vraiment très cool, et la partie déploiement semble particulièrement originale
    • J’espère une documentation plus détaillée
    • Je suis surtout curieux des parties Streams, Singletons et Optionals
  • J’aime bien le modèle de programmation
    • Je me demande s’il effectue des optimisations réseau lors de la réécriture de l’application
    • Je me demande comment il gère les goulets d’étranglement et la congestion réseau
  • Je me demande comment cela se compare à l’utilisation de Ballista pour les pipelines de données
    • Ce dernier est construit sur Apache Arrow et Apache Datafusion, ce qui lui donne de nombreux avantages