Ça va être un plaie à maintenir. Et ça va prendre un temps de dev 2 fois plus long.
Rust n'est pas fait pour ça. Ils auraient mieux fait de juste mieux coder leur bouzin avec un langage adapté. On fonce vers un avenir où Rust va être un choix de facto par erreur.
On a connu ça avec d'autres technologies, d'autres langages, d'autres framework... Calmez vous avez ce langage sérieux...
Microsoft réécrit le code de Microsoft 365 en Rust - ZDNet
https://www.zdnet.fr/actualites/microsoft-reecrit-le-code-de-microsoft-365-en-rust-39963998.htm
@metal3d pas du tout d'accord, au contraire. La force du système de typage est (à mon avis) la plus grosse force de Rust, et une application devient plus facile à maintenir quand on peut faire confiance (entre autres) aux steps de compilation.
@shavounet Rust n'est pas le seul langage typé statiquement. Par contre sa syntaxe n'est pas adapté à la maintenabilité d'un système bardé d'API. Il est long en compilation et n'offre pas d'abstraction suffisante pour réduire le temps de définition d'une archi.
Go, C#, etc... Si.
@metal3d la courbe d'apprentissage Rust est effectivement plus hardue, mais il y a pas mal de témoignages qui montrent que l'efficacité au moyen et long terme est aussi bonne que n'importe quel autre langage. Et au final la complexité qu'il représente est innérante à la construction d'applications de manière générale. Masquer cette complexité (et je pense à Go) ne fait que la déplacer dans la responsabilité du développeur de "coder comme il faut".
@metal3d Le typage n'est pas seulement statique, mais comporte un paquet de concepts (traits + génériques, les enums qui sont plus proches de sum types, ...) qui le rendent vraiment robuste. Ayant fait plus que ma part de Symfony : oui l'expérience n'est pas la même, mais une fois pris en main il est tout aussi capable (voir plus) de créer des abstractions puissantes.
@shavounet ce genre de typage est inhérent à des langages comme Rust. Go propose d'autres approches, C en propose d'autres et Java idem. On pourrait faire du ML en C, on pourrait faire des app de traitement de données en assembleur en recréant toutes les abstractions que l'on veut.
Au final, est-ce que ce serait une bonne idée, est-ce qu'on y gagne en ratio temps/perf ?
J'ai de sérieux doutes en ayant travaillé avec Rust.
Rust est vraiment excellent, mais pas adapté à tout.
@shavounet ça me rappelle un débat que j'ai eu avec un fan de Haskell qui m'a prétendu arriver à aller plus vite pour dev une API que moi avec PHP (à une certaine époque).
J'adore Haskell hein. Mais bon...
Le résultat était énorme. Son code tournait vite et ça n'utilisait pas beaucoup de RAM mais il a mis un temps pas possible à y arriver. Et le gain en perf était finalement pas fou fou.
Je comprends qu'on aime un langage et ses capacités. Mais faut pas faire n'importe quoi par conviction 😉
@metal3d et pour préciser : on a passé 6 mois dans ma boîte à réfléchir à une migration PHP vers Rust, même si au final c'est Go qui a été retenu (notamment pour la courbe d'apprentissage, et la capacité de recrutement...)
@metal3d et bien sûr c'est pas pour autant qu'il faut tout réécrire en Rust... Je préfère mille fois une app Symfony écrit proprement quand c'est adapté :)
@shavounet mais carrément. Rust a bien entendu d'énormes qualités, PHP en a d'autres, et Go encore d'autres. Rust c'est super sur du bas niveau et un besoin strict de sécurité de la mémoire. Mais pour des app cloud, franchement...
Là y'a une Rustmania qui m'inquiète vraiment.
PS : p'tain t'as du bol de pouvoir faire du Go dans ta boîte 😋
@shavounet je vais préciser que j'ai réalisé une étude pour un client entre Rust, Go et Java.
On a réalisé un POC structuré pour un SI cloud (scalé, conteneurisé).
Rust demandait 30% de temps en plus pour coder et le gain d'en perf était de 10% par rapport à Go.