De Python à GO à Rust : Un voyage débordant d’opinions

En cherchant un nouveau langage pour le backend, je suis naturellement passé de Python au nouveau favori : Go. Mais après seulement une semaine avec Go, je me suis rendu compte que Go n’était qu’une demi-avancée. Mieux adapté à mes besoins que Python, mais trop éloigné de l’expérience de développement que j’appréciais en faisant du Elm en frontend. J’ai donc essayé Rust.

Depuis Python,

Pour le développement backend, j’ai principalement utilisé Python 3 ces trois dernières années. Des scripts d’administration au machine learning en passant par les applications Flask/Django, j’ai beaucoup utilisé Python récemment, mais à un moment donné, ça ne me semblait plus juste. Pour être honnête, ce n’est pas vraiment à un moment « totalement aléatoire » que cela a commencé à ne plus me convenir, c’était quand j’ai commencé à apprécier la programmation avec un langage fortement typé : Elm.

J’avais cette fameuse sensation « quand ça compile, ça fonctionne », et une fois que vous avez expérimenté cela, il n’y a pas de retour en arrière possible. Vous essayez des choses, vous suivez les messages d’erreur conviviaux du compilateur, vous corrigez les choses, et puis tada, ça fonctionne !

À ce stade, je savais ce que je voulais du « langage backend parfait » :

1. Typage statique et fort
2. La plupart des vérifications effectuées au moment de la compilation (s’il vous plaît, pas d’exceptions !)
3. Pas de null
4. Pas de mutabilité
5. Gère bien la concurrence

Je vous vois venir : « hé, c’est Haskell ! » Oui, en effet, mais pour une raison ou une autre, je n’ai jamais réussi à faire quoi que ce soit avec Haskell (et j’ai beaucoup essayé). Peut-être que c’est juste moi, mais de l’extérieur, l’état d’esprit Haskell semble élitiste, la documentation et les exemples pratiques manquent et c’est difficilement accessible pour un débutant. « Learn you a Haskell for great good » est génial mais très long à lire et trop abstrait pour moi.

« Hé, et Scala alors ? » Que voulez-vous dire par Scala ? Le meilleur Java ? Le langage de programmation fonctionnelle avec Scalaz ? Le langage de programmation orientée objet fonctionnelle qui peut ou ne peut pas échouer à l’exécution avec une java.lang.NullPointerException et nécessite une JVM de 4 Go en cours d’exécution ? Je l’ai essayé il y a quelques années et définitivement, ce n’est pas pour moi.

Après avoir discuté avec quelques personnes, j’ai décidé d’essayer Go. Il a un compilateur, pas d’exceptions, pas de null (mais des valeurs null) et peut gérer la concurrence agréablement.

À Go,

J’ai décidé de réécrire un projet interne qui était déjà fait en Python en utilisant Go. Juste pour ressentir les différences entre les deux.

Premier sentiment : apprendre Go était tellement facile. En une soirée, j’étais capable de compiler un prototype du projet avec des fonctionnalités de base développées et quelques tests écrits. C’était un sentiment très agréable, j’ajoutais des fonctionnalités très rapidement. Les messages du compilateur étaient utiles, tout allait bien.

Et à un moment donné, la tragédie a commencé. J’avais besoin d’ajouter un champ à une structure, donc j’ai juste modifié la structure et j’étais prêt à analyser les messages du compilateur pour savoir où cette structure était utilisée afin d’ajouter le champ là où il était nécessaire.

J’ai compilé le code et… aucun message d’erreur. Tout allait bien. Mais ?! Je venais d’ajouter un champ à une structure, le compilateur devrait dire que mon code n’est plus bon parce que je n’initialise pas la valeur où il le faut !

Le problème est que, ne pas fournir de valeur à une structure n’est pas un problème en Go. Cette valeur sera par défaut à sa valeur zéro et tout compilera. C’était le coup d’arrêt pour moi. J’ai réalisé que je ne pouvais pas compter sur le compilateur pour me couvrir quand je faisais des erreurs. À ce stade, je me demandais : pourquoi devrais-je me donner la peine d’apprendre Go si

le compilateur ne peut pas faire beaucoup mieux que Python et mypy ? Bien sûr, la concurrence est bien meilleure avec Go, mais le désavantage de ne pas pouvoir compter sur le compilateur était trop pour moi.

Ne vous méprenez pas, je pense toujours que Go est un progrès par rapport à Python et je recommanderais définitivement aux gens d’apprendre Go plutôt que Python s’ils devaient choisir l’un des deux. Mais pour mon cas personnel, en tant que personne qui connaissait déjà Python et voulait quelque chose de beaucoup plus sûr, Go n’apportait pas assez à la table dans ce domaine spécifique.

Vers Rust,

Donc Go n’était plus une option car je me suis rendu compte que ce dont j’avais vraiment besoin était un compilateur utile : un compilateur qui ne devrait pas compter sur le fait que je sais coder (comme cela a été prouvé être faux de nombreuses fois). C’est pourquoi j’ai jeté un œil à Rust.

Rust n’était pas mon premier choix car il se présente comme un « langage système », et je suis plus un développeur web qu’un développeur système. Mais il avait quelques points de vente très convaincants :

• Pas de valeurs null mais un type Option (vérifié au moment de la compilation)
• Pas d’exceptions mais un type Result (vérifié au moment de la compilation)
• Les variables sont immuables par défaut
• Conçu avec la concurrence à l’esprit
• Sécurité mémoire par conception, pas de ramasse-miettes

J’ai décidé de réécrire le même programme que celui que j’avais fait en Python et Go. L’intégration a été beaucoup plus difficile qu’avec Go. Comme je l’avais fait avec Go, j’ai essayé de plonger tête première, mais c’était trop difficile : j’avais besoin de nouveaux concepts spécifiques à Rust comme la propriété ou les durées de vie pour comprendre le code que je voyais sur StackOverflow. Donc, je n’avais pas d’autre choix que de lire le Rust Book, et cela m’a pris deux semaines avant de pouvoir commencer à écrire du code (rappelez-vous qu’avec Go, cela m’a pris une soirée).

Mais après cette courbe d’apprentissage initiale abrupte, j’appréciais écrire du code Rust, et je l’apprécie toujours. Avec Rust, je n’ai pas besoin de me faire confiance, je dois juste suivre le compilateur et si je le fais, cela fonctionnera très probablement si cela compile. En fin de compte, c’est le sentiment principal que je recherchais en cherchant un nouveau langage backend.

Bien sûr, Rust a beaucoup d’inconvénients :

• C’est assez nouveau et les choses bougent très vite. J’utilise futures-rs et hyper.rs dans mon projet, et trouver une bonne documentation a été vraiment difficile (bravo aux gens sur irc.mozilla.org#rust-beginners pour l’aide).
• Il vous force à penser à des choses auxquelles vous n’êtes pas habitué lorsque vous venez de langages plus « high-level » : comment la mémoire est gérée (avec les durées de vie et la propriété).
• Les messages du compilateur ne sont pas toujours faciles à comprendre, surtout lorsque vous combinez des futurs et leurs types longs et étranges.
• La mutabilité est autorisée, donc vous pouvez vous faire écraser par des effets secondaires.

Mais, il a aussi beaucoup d’avantages :

• C’est incroyablement rapide
• L’outillage est bon (cargo, rustfmt)
• La plupart des choses sont vérifiées au moment de la compilation
• Vous pouvez potentiellement faire tout ce que vous voulez avec, d’un navigateur à une application web, en passant par un jeu.
• La communauté est accueillante
• Il est soutenu par Mozilla

En conclusion,

Go est cool mais ne fournit pas assez de sécurité de type pour moi. Je préférerais rester avec Python et son écosystème que de risquer de réécrire des choses en Go si je n’ai pas besoin de concurrence. Si j’ai besoin de concurrence, je n’utiliserais toujours pas Go car son manque de sécurité de type me frappera sûrement à un moment donné.

Rust est le candidat parfait pour la concurrence et la sécurité, même si le crate futures-rs est encore à un stade précoce. Je soupçonne que Rust pourrait devenir la norme de facto pour de nombreux besoins backend à l’avenir.

Pour un article de blog plus approfondi discutant des différences entre Go et Rust, assurez-vous de vérifier cet incroyable post par Ralph Caraveo (@deckarep) : Paradigms of Rust for the Go developer.

Au moins, je pense que j’ai trouvé en Rust mon nouveau langage préféré pour le backend.