Comparer des langages de programmation est difficile, et il est facile d'être mal interprété.
Je n'ai pas jugé utile de le préciser mais je le fais à présent: loin de moi l'idée d'ouvrir une guerre de paroisses, ma question est tout à fait naïve – je ne connais absolument pas Rust et je suis curieux d'avoir des éléments de comparaison concrets avec OCaml. Donc du coup, merci beaucoup pour ta réponse!
Il y a une vraie culture crypto dans la communauté Rust, ce qui permet d'apprendre rapidement et de discuter.
Ça c'est un trait vraiment particulier, est-ce que tu sais l'expliquer historiquement?
Petits détails techniques : compiler des programmes en Rust est très facile, et il y a des threads (et personne pour nous expliquer que ce n'est pas la bonne façon de programmer).
Qu'est-ce qui ne vas pas avec les threads? Dans le cas de services dont le terme dominant de la performance est assujetti aux IO, l'approche alternative à la Lwt/NodeJS basée sur un thread système pour les IO, un thread système pour la logique de l'application, et des threads légers collaboratifs dans l'application et une échelonnement ("scalabilité" en bon franglais) horizontal pour monter en charge est maintenant bien mise à l'épreuve; mais c'est totalement hors de propos pour un gestionnaire de version, non? Du moins pour la partie client. ;)
[^] # Re: Repos
Posté par Michaël (site web personnel) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 3.
Je n'ai pas jugé utile de le préciser mais je le fais à présent: loin de moi l'idée d'ouvrir une guerre de paroisses, ma question est tout à fait naïve – je ne connais absolument pas Rust et je suis curieux d'avoir des éléments de comparaison concrets avec OCaml. Donc du coup, merci beaucoup pour ta réponse!
Ça c'est un trait vraiment particulier, est-ce que tu sais l'expliquer historiquement?
Qu'est-ce qui ne vas pas avec les threads? Dans le cas de services dont le terme dominant de la performance est assujetti aux IO, l'approche alternative à la Lwt/NodeJS basée sur un thread système pour les IO, un thread système pour la logique de l'application, et des threads légers collaboratifs dans l'application et une échelonnement ("scalabilité" en bon franglais) horizontal pour monter en charge est maintenant bien mise à l'épreuve; mais c'est totalement hors de propos pour un gestionnaire de version, non? Du moins pour la partie client. ;)