Rust, une alternative fiable?

Donc ce que tu es en train de me dire, c’est qu’il vaut mieux envoyer du code à un serveur d’intégration continue, attendre qu’il fasse tourner une batterie complète de tests, et voir à ce moment-là si tout va bien, plutôt que d’avoir un compilateur qui filtre dès le départ une bonne partie des erreurs potentielles ? Que ça, ça fait gagner du temps ? Permets-moi d’être légèrement sceptique…

Tu ignores volontairement deux éléments :

• les tests tu peux les faire tourner en local, suivant les langages et les technos les suites courtes font même partie du build (c'est le cas en Go : les programmes compilent à la vitesse de l'éclair et les tests se lancent et s'intègrent directement dans le code), donc tu n'as pas besoin de faire un aller retour avec un serveur d'intégration pour les erreurs courantes. Le rôle du serveur d'intégration est de ne pas laisser merger un code non valide au travers de suites de tests courtes exécutées pendant la revue de code d'une Pull Request d'une part (on peut d'ailleurs l'associer à un gatekeeper pour automatiser cette tâche et éviter de merger à tort), et de détecter les erreurs les plus insidieuses après le merge au travers de suites de tests longues (end-to-end, régression) d'autre part.
• combien de temps et de neurones le développeur moyen va-t-il cramer avant d'avoir fini son code initial ? Sous prétexte que le compilateur renforce la memory safety, est-ce que cela légitime d'imposer des contraintes à un code dont on sait qu'il restera mono-threadé toute sa vie ? Et quand bien même, dans un projet en Rust, tu auras toujours besoin d'écrire des tests pour ton code, donc à quoi ça sert de s'infliger toutes ces contraintes pré-compilation ? Si le compilo me dispensait de tester mon code, j'y regarderais à deux fois, mais ce n'est pas le cas, donc le jeu ne me semble pas en valoir la chandelle.

Si vous avez fait un peu de langage C ou du PHP, la courbe d'apprentissage de Go est assez rapide. Après je m'en sers principalement pour faire du Web…

Quant au compilateur, avec le task manager Gulp, c'est tout à fait possible d’auto-compiler le programme à la sauvegarde du fichier (comme avec NodeJS).

PS : la version 1.7 de Go est sortie il y a quelques jours.

Je sais que je vais devoir me frotter avec le C/C++. Avec mes connaissances actuelles, je peux tout à fait lire du code C ( qui possède une syntaxe minimaliste et simple ) mais je sais que je vais m'y frotter un jour ou l autre, je préfère être prêt et rigoureux lorsque cela arrivera.

Je ne comprends pas bien en quoi Rust pourrait te rendre plus rigoureux que C++. À mes yeux les courbes d'apprentissage des deux langages sont équivalentes, les deux permettent de manipuler des mécanismes similaires, sauf que C++ te demande plus de rigueur que Rust pour gérer correctement la const-correctness ou la sémantique de mouvement.

Je veux bien croire que le langage t'attire (et aucun de mes messages précédents n'a eu pour but de te dissuader de l'essayer, mais plutôt de tempérer les rustacéens de tout poil en disant clairement quelles sont mes réserves sur ce langage), mais à ce moment là, sois conscient que ce n'est pas en laissant un compilateur être rigoureux à ta place que tu deviendras toi-même rigoureux pour autant. Apprendre Rust parce que le langage te séduit est en revanche une raison parfaitement valable, et laisser C et C++ pour plus tard parce que là tout de suite tu as envie de faire du Rust également. Par contre voir Rust comme un intermédiaire utile avant de te lancer dans C++ serait une erreur, à mon humble avis.

Je ne vois absolument pas le rust comme un intermédiaire du C++ ( comme je ne considère que aucun langage est le prérequis d un autre). Je suis juste séduis par le langage et sa philosophie. De plus je suis un peu lassé des C++iens qui ne trouvent que le C++ sans aucunes autre alternative.

Y'a peut être de bonnes raisons si ces fameuses alternatives ne décollent pas. Il suffit de voir le D qui était foutrement excellent sur le papier (puisque créé exprès pour combler les lacunes du C++, par un type notoirement connu pour ses apports au standard du C++) et le flop spectaculaire qui en a résulté pour se rendre compte que la viabilité (l'adoption) d'un langage n'est clairement pas déterminée par ses seules qualités intrinsèques.

Dans ces conditions ça ne me choque pas qu'on dise encore aujourd'hui qu'il n'y a pas de vraie alternative à C++. Pour qu'un langage soit considéré comme tel il faudrait qu'il soit un minimum adopté dans l'industrie, ce qui n'est même pas encore le cas de Go, qui reste majoritairement accroché à Google, même si les types qui l'ont développé sont la joyeuse bande de demi-dieux des bell labs (Ken Thompson, Rob Pike et consorts) à qui l'on doit grep, sed ou même l'algorithme standard de compilation d'une expression régulière en AFN.

Et pour qu'un langage orienté programmation système soit adapté par l'industrie, j'ose espérer qu'une des conditions est qu'il soit stable. Or, en moins de 9 mois sur l'année 2016, on a vu pas moins de 6 versions de Rust :

1. 21 janvier : Rust 1.6
2. 3 mars : Rust 1.7
3. 14 avril : Rust 1.8
4. 26 mai : Rust 1.9
5. 7 juillet : Rust 1.10
6. 18 aout : Rust 1.11

Et ce ne sont pas de petites versions de bugfix ! On y parle d'énormément de stabilisation de bibliothèques standard et d'API, mais aussi de nouvelles possibilités du langage (1.8 : possibilité de surcharge de += et -=), etc.

Ça veut dire que si j'ai un projet d'importance moyenne, je vais avoir 2 versions dans les 3 mois entre le moment où je commence les études préliminaires et le moment où je commence le développement, et 4 autres versions dans les 6 mois entre le moment où je commence le développement et celui où je livre le premier produit fini. Ça me paraît difficilement acceptable pour quelque chose d'aussi sensible que la programmation système !

Je voudrais pas dire mais Rust est un langage jeune, faut lui laisser un peu le temps de se stabiliser avant de regarder ça, non ?

Tout à fait d'accord, mais du coup pourquoi le versionner en 1.x qui dénote théoriquement une version stable ?

Spacefox : Ça fait un peu l'oeuf ou la poule. Un langage a besoin de gens pour se développer et se stabiliser mais les utilisateurs ciblés ont besoin de quelque chose de stable.

Tu peux gérer ça autrement, alors. Par exemple, décider d'une version 1 minimale mais stable, et préparer des bêta et des RC pour la version suivante (au lieu de les appeler 1.x).

Ce n'est pas dérangeant qu'un langage aussi jeune soit en plein développement, au contraire. Par contre, une grande vitesse de développement et un versionnement bizarroïde risquent de rendre son adoption par une industrie (les logiciels bas niveau) d'autant plus lente que cette industrie est conservatrice.

Je suis mitigé, mais je penche plutôt vers l'avis de SpaceFox.

D'un côté, il est clair qu'un langage jeune doit évoluer rapidement, apprendre rapidement de ses erreurs, et donc être releasé le plus souvent possible. Donc le fonctionnement de Rust n'est pas déconnant à ce niveau.

De l'autre côté, il faut aussi voir l'image que cela renvoie du langage : une release tous les 2 mois, dans l'industrie, ça veut dire "techno instable". Si je prends ma société en exemple, qui édite un logiciel dont une très grosse partie des composants sont au niveau système (on parle de systèmes de fichiers distribués, là), même si on n'a pas peur d'intégrer des technos hyper récentes dans le projet (Docker, NodeJS, Salt…), cette partie "Core", système, actuellement en C, reste tellement sensible qu'il est impensable d'utiliser une techno aussi volatile pour l'instant, d'autant plus que le système doit être supporté sur des OS multiples (dont le cauchemardesque CentOS 6 qui nous force à rester compatibles avec Python 2.6 pour encore un paquet de temps).

Ça veut donc dire que le point de vue d'une boîte la plus ouverte possible aux nouvelles technos, dans le créneau de Rust (des produits comprenant de la programmation système), ne peut être que "oui, ça a l'air cool, c'est prometteur, mais pour l'instant c'est pas stable alors on n'y touche pas et on ne peut même pas se permettre d'essayer".

Le problème, c'est que l'adhésion de l'industrie à un langage le plus tôt possible est une clé dans le succès dudit langage. Si je reprends le parallèle avec Go, on a Google et Docker en fer de lance de la techno, donc à moins que Docker ne claque dans les 5 ans (ce qui est impensable à l'heure actuelle), le langage et sa communauté vont continuer à se consolider. Pour Rust, c'est moins sûr : si l'industrie ne l'adopte pas (en le criant haut et fort), alors sa communauté ne dépassera pas la "poignée d'enthousiastes", et le langage restera à côté de Haskell et de D, dans les douves.

En conclusion, le cycle de release de Rust devrait être à l'image du public visé. Ça a l'air idiot, mais c'est pourtant critique. Typiquement, le produit principal ma boîte, qui vise des domaines d'application assez frileux en termes de stabilité (on a quand même la société générale, Orange et General Electrics en clients, pour ne citer qu'eux — et je ne pense pas qu'on puisse les qualifier de "peu exigeants" ), suit un cycle de release difficilement conciliable avec le continuous delivery de Rust (on a l'obligation de maintenir le soft en vie dans plusieurs version majeures simultanément, avec des versions LTS qui rassurent les plus hermétiques au changement), sans lequel ces clients n'auraient même pas pris 5 secondes pour envisager d'utiliser notre soft.

Alors j'ai peut-être l'air de faire mon vieux con d'industriel avec mon discours, mais pour moi la remarque de SpaceFox lève un détail hyper important pour la survie de Rust ; en l'état actuel, il est probable que son cycle de release desserve Rust plus que ça ne le sert vraiment.

T'es au courant que y'a pas que l'industrie dans la vie ? Certes la stabilité ça peut faire peur aux industriels mais merde quoi, on parle pas de remplacer le C++ par Rust le 1er septembre 2016 ! Laissez le temps à Rust de mûrir, et pendant que les gens qui pensent que la question c'est de savoir si demain je peux migrer toute la codebase de l'entreprise vers du Rust couinent sur la stabilité, ceux qui s'intéressent à Rust peuvent faire des choses sympas avec (et sinon Servo c'est pas de l'industrie peut-être ?).

Je suis parfaitement au courant, merci. Puis-je te suggérer de garder le calme ?

Remplace "Industrie" par "Gros projets open source" dans mon post, et celui-ci restera toujours aussi valable et aura la même conclusion. Pour des projets comme OpenStack, Apache, ou la plupart des distributions Linux, la problématique est exactement la même.

Sachant que la plupart des gros projet open-source sont finances par l'industrie au moins en partie et sont souvent professionels.

L'adoption massive d'un langage passe necessairement a un moment donne par l'industrie (ou une part de celle-ci) ce qui implique qu'etant donne le besoin de stabilite, Rust n'a pas ou ne peut avoir la pretention a etre un remplacement de quiconque pour le moment dans la vie reelle. Alors apres on pourrait se dire que si plein de gens utilisent Rust de maniere non-pro, surtout des etudiants, dans quelques annees ils pousseront a l'adoption du langage.

Sauf que dans la pratique, c'est bien souvent le client qui guide les besoins et le client il capitalise souvent sur ses infrastructures et a donc besoin de compatibilite sur XXX annees, d'ou une inertie tres importante dans l'evolution de l'adoption des technologies (et aussi pourquoi de mauvais langages peuvent s'imposer).

J'ai l'impression qu'avec l'adoption massive du cloud, les societes technologiques aurons dans le futur un poids plus important par rapport au client via un controle plus grand sur les environnements de production.

En attendant Rust ne m'apporte rien de significatif par rapport a C++.

C' est bien embêtant car chaque participant soulève des arguments tot a fait recevable et même bien vu mais globalement les "attendre la stabilité et l'âge mur de Rust " sont plus nombreux que les partisans du Rust alors peut être que je vais changer de decision et commencer par le C++ et à l'avenir m'intéresser plus au Rust. Je suis perplexe…

C'est pareil pour toutes les technologies : il y a les early adopters et les autres.

Chacun des deux groupes n'a pas les mêmes besoins, c'est à toi de voir de qui tu te sens plus proche.

Essaie les deux, joue un peu avec et tu te feras ta propre opinion.

Sinon je tiens à souligner que ces histoires de stabilité déjà à ce stade du développement de Rust, de un on s'en contrefout pour des projets amateurs, et de deux vous croyez vraiment que Linux ou le langage C étaient considérés "stables" au bout de 3 ans ?

Non, mais on ne les recommandait pas aux gens cherchant une alternative à Unix (c'était Minix qui avait la cote à l'époque).

Bon je commence à comprendre que ce débat ne peut pas vraiment trouvé d'issues donc je vais suivre le conseil de grimur et m'essayer aux deux langages. Je reviendrais plus tard avec ma propre idée.

On ne s'en contrefout pas du moment que la question est de savoir si à l'heure actuelle Rust est (je cite le titre du thread) "une alternative fiable" à C++ dans le domaine de la programmation système.

Et à cette question, la réponse est : oui c'est une alternative, avec de bonnes idées, mais que l'on ne peut certainement pas considérer comme fiable à l'heure actuelle, pour toutes les raisons mentionnées plus haut, n'en déplaise à ses aficionados.