[Choix langage] Go / Rust

Hello,

En dehors des considérations pratiques dans le cadre d’une application particulière, je pense que Rust est beaucoup plus intéressant à apprendre que Go.

En dehors des goroutines, Go est somme toute un langage assez classique qui n’apporte pas beaucoup sur le plan conceptuel. Rust introduit entre autre les notions de "lifetime" (qui lui permet de se passer de GC et de l’overhead que ça induit au runtime), de "trait" (qui permet de se passer des mécanismes de l’OO plus classiques comme l’héritage pour abstraire son code), un système de type sacrément bien foutu (malgré quelque lourdeurs ça et là)… Même si toutes ces idées ne sont pas forcément nouvelles (beaucoup viennent du monde de la programmation fonctionnelle), il est intéressant de les voir regroupées dans un langage destiné à la programmation système et haute performance.

Encore une fois, ce ne sont que des considérations conceptuelles indépendante des contraintes applicatives, mais je pense que ça peut intéresser les futurs lecteurs de ce sujet.

Rust semble quand à lui plus complexe à appréhender mais qui sur le long terme permettrai de faire " plus de choses "

D’un point de vue intrinsèque, les possibilités offertes par les deux langages sont très similaires. En revanche, à long terme, le système très pratique de packaging offert par Rust avec cargo pourrait bien lui permettre de prendre le pas sur Go d’un point de vue écosystème.

J’ai envie de dire que le choix que tu fais maintenant pour ton stage n’est pas définitif pour le reste de ta vie, tu peux bien apprendre Go maintenant (probablement beaucoup plus simple et rapide à appréhender, donc mieux adapté à la situation d’un stage), jouer un peu avec, puis te pencher sur Rust (ou encore autre chose) plus tard et voir ce que tu préfères.

Je me demande si tout le monde se rend bien compte ici que l’on est en train d’orienter un débutant dont le stage imminent touche au domaine du web, vers un langage système notoirement connu pour être difficile à apprendre et à manipuler efficacement ?

Je me permets de rééquilibrer la balance parce que même s’il est beaucoup moins sexy sur le papier que Rust (ce que j’admets volontiers), et qu’il ne répond pas à un idéal académique, on ignore souvent ce qui a poussé des gens comme Ken Thompson et Rob Pike à développer Go : le vrai monde, c’est-à-dire la réalité du développement, qui comprend la facilité à déployer, la gestion des dependances dans une codebase qui grossit, la vitesse du build de tout un projet sur un système d’intégration continue, et le fait que le temps de cerveau d’un développeur coûte beaucoup plus cher à l’entreprise que celui du CPU d’un ordinateur. Toutes ces problématiques ont été prises en considération jusque dans le design du langage, pas seulement son modèle de concurrence !

D’abord, il est notoire que le plus gros de l’écosystème de Go et donc son domaine d’application usuel, contrairement à celui de Rust, c’est le backend des services web ! Il n’y a qu’à consulter la liste des packages disponibles dans cet écosystème pour s’en apercevoir, et ça n’a rien d’étonnant puisque le langage est développé par Google.

Go a été pensé pour être versatile, à l’image de Python (c’est-à-dire modelable et très rapide à développer), en proposant notamment un modèle de concurrence basé sur l’idée il faut communiquer pour pouvoir coopérer, pas l’inverse. Ce que ce modèle a de particulièrement intéressant (et ce qui fait toute son élégance), c’est qu’il est simple à comprendre, à appréhender, immédiat à appliquer, et qu’une fois bien compris il permet de se passer de milliards de contraintes formelles pour rendre la programmation concurrente possible sans se péter les dents : il s’agit d’apprendre à penser son problème correctement plutôt que d’obéir à un compilateur qui le fait pour nous de façon rigide, ce que je trouve personnellement beaucoup plus enrichissant. Les autres idées qui ont poussé le développement de Go sont sa vitesse de compilation (parce qu’à la longue, sur de vrais gros projets, ça devient un vrai facteur limitant), et le fait qu’il incite les developpeurs à vraiment produire du code modulaire. Renseignez-vous sur le pourquoi du comment de ce langage (les articles de google sont légion à ce sujet) avant de dire des bêtises du style Go n’apporte rien en dehors des goroutines, ou de le snober pour manque d’académisme. Le système packages dont Rust s’ennorgueillit, Go en avait apporté tous les avantages 10 ans plus tôt !

Pour finir, je n’ai vraiment rien contre Rust et je trouve que c’est un langage très intéressant, mais à la fin de son stage qui va durer grand max 6 mois, peut-être que le PO voudra avoir accompli autre chose qu’apprendre à utiliser son langage de programmation, non ?

Que le compilateur soit rapide et que le langage soit fait pour être modulaire, ça n’a rien de particulièrement nouveau comme objectif

Que le langage soit pensé de telle façon que la compilation d’une solution entière se fasse en moins d’une seconde (il ne s’agit pas d’une banale optimisation du compilateur), à l’époque où Go a été créé, il était le seul. Certes aujourd’hui ce n’est plus quelque chose de tellement novateur puisque tous les autres se sont alignés avec plus ou moins de succès, mais il ne faut pas négliger le fait que derrière Go, tu as les travaux de gens qui ont toujours eu une influence considérable sur le domaine, y compris en recherche fondamentale, depuis les années 1960 (Ken Thompson en particulier) : les snober pour le manque d’académisme sur Go a quelque chose de plutôt rigolo.

Il serait judicieux, à mon avis, de se demander comment et pourquoi ces types sont arrivés à ce résultat.

Personne n’a dit que Go était un langage inintéressant à utiliser, ce que j’ai dit c’est qu’il est inintéressant à apprendre.

Et je pense que tu te trompes lourdement à ce sujet.

C’est le seul langage que je connaisse dont les idiomes incitent délibérément à penser la concurrence de cette façon. Et d’expérience, adopter cette façon de penser dans d’autres contextes n’est pas trivial : typiquement l’equipe avec laquelle je bosse a du mal à penser de cette façon en Python, quand bien même la codebase sur laquelle on bosse a inclu ces idiomes dès sa conception (alors que je ne connaissais pas vraiment Go à cette époque… Si c’était à refaire j’aurais probablement poussé Go pour ce projet).