si tu veux faire un site web qui doit gerer un packet de client, et tout les langage semi compilé, GO, C#, java,
Go n’a pas de machine virtuelle, hein, il est compilé. C’est juste que les binaires embarquent un garbage collector.
je sais que discord a fait un comparatif entre Rust et GO, ca avait pas mal parlé car ils utilisent une vielle version de GO avec une alpha de Rust, ce qui n’est pas comparable sous Go ils existe de bon logiciel (par exemple Victoria Metrics qui c’est forgé une réputation rapidement) et coté perfs, ils est bon, vraiment
Surtout ils l’ont fait sur un de leurs services les plus critiques, qui se bouffe en permanence une charge réellement massive, et sans préciser leur contexte. Il s’agissait d’un cas typique où c’était vraiment le langage lui-même qui les limitait, mais il y a fort à parier qu’ils n’auraient jamais pu acquérir la même comprehension du problème ni quelque chose qui marche aussi bien, aussi tôt, s’ils étaient d’abord parti sur Rust.
De mon point de vue, Rust est réellement un langage excellent quand il s’agit de récrire les choses pour les rendre plus rapides, plus safe et tirer le meilleur parti possible de la machine oùtourne le soft. Mais quand il n’y a que 10% du code à récrire, ce serait un gâchis de ressources (humaines) assez énorme de tout faire avec : toujours par expérience personnelle, ça prend un temps de dingue de réfléchir à la façon dont un programme doit être conçu en Rust, alors quand il nous manque en plus l’expérience du problème que le programme sera amené à résoudre, ainsi que la connaissance de ce que le programme devra réellement faire à moyen terme, ça ne facilite pas les choses.
Aujourd’hui, les boîtes qui estiment pouvoir se permettre de récrire des parties de leur code en Rust sont encore rares, et ce n’est sûrement pas parce que Rust est "trop jeune". C’est simplement un problème de retour sur investissement : on travaille aujourd’hui dans des environnements où l’on sait parfaitement gérer une partie du code qui est trop lente ou qui plante de temps en temps, et l’on sait qu’avant d’aboutir à une spec suffisamment stable pour un service ou autre, il va falloir itérer sur son code un paquet de fois.
Dans ces conditions, il est effectivement plus malin de travailler "tous les jours" avec un langage malléable, qui permette d’avancer rapidement, à moindre coût, tout en gardant en tête que ce code n’est pas gravé dans le marbre, et le considérer comme jetable (c’est-à-dire que l’architecture doit le permettre, mais c’est pas un hasard si on ne jure plus que par le microservice aujourd’hui) : si demain mon service est feature complete mais pas assez rapide/safe et que ça pose un problème significatif, alors il sera temps d’évaluer mes options pour corriger ça, et le récrire en Rust est une de ces options.
Partant de là, non, tu n’es pas vieux. Tu mûris simplement. Avant d’arriver à ces considérations, il y a vraiment une tetrachiée de choses à penser et à bien faire, comme le fait de rendre ton système observable par exemple. Tout ça, et la facilité avec laquelle tu le fais, est finalement beaucoup plus critique dans ton métier que les technos en elles-mêmes. Avant d’arriver à la conclusion "j’ai besoin de refaire ça en Rust" il faut déjà répondre à :
- Est-ce que je sais comment se comporte ce code ?
- Est-ce que je peux facilement le surveiller ?
- Est-ce que j’observe un phénomène problématique ?
- Est-ce que je peux le caractériser ?
- Est-ce que je sais l’expliquer ?
- Est-ce que le problème en question est impactant pour les utilisateurs ?
- Entraîne-t’il un surcoût de maintenance pour moi ?
- Est-il l’un des plus impactants à l’heure actuelle ?
- Est-ce que je peux y remédier facilement ou bien c’est vraiment ma techno qui est en cause ?
Et pour répondre à la plupart de ces questions, tu as déjà des choses techniques à mettre en place. 
