Technology Review raconte, avec un peu d’emphase, « comment Rust est passé d’un projet parallèle au statut de langage de programmation le plus aimé du monde ».
Le journal du MIT rappelle l’histoire du langage, du début en 2006, lorsque Graydon Hoare, développeur de 29 ans à Mozilla, s’est penché sur la façon dont les ascenseurs fonctionnaient parce que, disait-il, « c’est ridicule que nous, les informaticiens, ne puissions même pas fabriquer un ascenseur qui fonctionne sans planter ! », jusqu’à l’adoption du langage par Facebook, Dropbox ou encore AWS.
L’ancien responsable de l’équipe Rust chez ce dernier, Shane Miller, salue, dans l’article, l’efficacité du langage. Une étude [PDF] citée par le journal montre que le code d’AWS écrit en Rust utilise moitié moins d’énergie que du code similaire d’AWS écrit en Java.
« Si Rust est né en 2006, il sort aujourd'hui de l'adolescence et entre dans la maturité », explique Technology Review, citant aussi l’adoption du langage par les industries de l’automobile et de l’aérospatiale.
Commentaires (46)
#1
J’ai dû louper un truc, mais cette étude ne semble pas parler d’AWS. Technology Review dit : « a study of Rust-based code found it runs so efficiently that it uses half as much electricity as a similar program written in Java, a language commonly used at AWS. »
Mais, surtout, je trouve étrange de pointer Java (et non C++), comparé à Rust.
#1.1
Je pense que tu trouveras beaucoup moins de code en C++ qu’en JAVA sur des serveurs Web.
Mais comparer un langage compilé en code machine avec un langage compilé en byte code en ce qui concerne l’efficacité énergétique, ce n’est pas pertinent. En tout cas, le résultat n’est pas trop surprenant. En fait, si, il est surprenant, j’aurais pensé qu’il y aurait plus qu’un facteur 2.
#2
Disons que de nos jours, on se risque peu à faire du C++ en entreprise. Quand on parle de développements en entreprise, on parle généralement de trucs faits en java, pas en C++. Le C++ est un langage risqué qui nécessite de très bons devs pour avoir un bon résultat là où Java nécessite des profiles (beaucoup) moins (chers) exigeants et propose avec des cadriciels très étoffés.
Maintenant, on pourrait aussi comparer Rust à Go … après tout, on a une nouvelle génération de langages, avoir un comparatif avec les contemporains n’est pas dénué de sens…
https://programming-language-benchmarks.vercel.app/go-vs-rust
#3
Java est interprété alors que C++ et Rust… sont des langages compilés qui ont donc des gains pratiques en terme de rapidité, utilisation de la mémoire… et donc de consommation d’énergie, dès la 1ère ligne de code.
Java étant très utilisé côté serveur et portables Android, il parait pertinent de le comparer avec Rust, non ?
#4
Pas mieux! Niveau comparaison de serviettes et de torchons, on se dit que si le type d’AWS ancien responsable Rust chez eux ose cela, c’est peut-être mieux pour eux qu’il soit désormais ailleurs…
Niveau auto/aérospatial, pourquoi pas. Mais je verrais quand même plutôt le second (mais avec des cycles d’étude à 10 ans, c’est quand même pas pour demain) que le premier, car tant que le C fera mieux niveau performance, donc avec un impact sur le coût matériel d’autant plus important que les chiffres de production le sont, AMHA il restera préféré (combiné à des outils d’analyse de code). Surtout que c’est pas du soft évoluant rapidement.
Ne pas oublier que Rust a pris son envol chez Mozilla, qui développe 2 applicatifs réseau majeurs et évoluant rapidement: Là on comprends l’apport de Rust.
#5
Ah, tu dois pas faire de l’embarqué alors! On y a même le plus souvent le C++ sans le ++, au moins au niveau plateforme et comme c’est d’ailleurs le cas de tout OS majeur: Quand le moindre ‘new’ va te provoquer des allocations derrière ton dos, c’est pas trop un domaine ou on apprécie, au mieux, voir ou ce serait tout simplement viable! Et c’est globalement valable pour tout langage objet.
#6
L’embarqué est un domaine de niche, et les personnes qui y travaille n’ont généralement pas besoin qu’on leur explique les avantages du C ou du C++.
Dans l’écrasante majorité des entreprises où je travaille, c’est le règne de java et spring.
#6.1
l’embarqué un domaine de niche, ahah la bonne blague.
la plupart des appareils électroniques contient un soft embarqué.
Avec les IoT, c’est en train d’exploser.
#6.2
Et du coup on fait des VMs embarquées pour pouvoir y mettre du java allégé
#7
Et on fait du Javascript sur de l’ESP32, comme on faisait du basic interprété en 2000 sur des micro contrôleurs, ou du .Net sur des contrôleurs intermédiaires (ainsi que Java et micro java). Mon mini VP Samsung de 2010 (environ) c’était une carte avec 16Mo de RAM, un linux et tout en Qt (donc C++ et librairie alors réputée sous Linux “gourmande”).
C et C++ sont les langages de choix habituels, mais n’importe quel langage peut fonctionner.
A voir si ça compense le coût énergétique dépensé lors du développement (java étant maîtrisé et facile à comprendre et bien fourni niveau bibliothèques avec une doc éprouvée)
Ensuite, c’est comme les comparaisons C/C++ vs Java du début du millénaire: tout dépend du soft et du temps passé en CPU (énormément de serveurs ne consomment pas le CPU dans le soft Java/C# ou autre mais dans le chiffrement/déchiffrement, l’interprétation de texte et la concaténation de texte, vive le web et le couplage mou)
#8
Euh…je pense que tu n’as pas idée des volumes de code pondu en java chaque année dans les entreprises, et même pour l’IoT on utilise bien plus souvent Java que C++ pour la couche de backend/gestion/centralisation.
#8.1
oui pour sur!
Mais de la à dire que l’embarqué est marché de niche il y a monde.
Par exemple une voiture, il y a une dizaine de contrôleurs tous codés en C pour des contrainte de temps réel et de coût aussi.
#9
Pour info, le noyau Linux (qui est actuellement écrit en C et C++ va passer en Rust dans quelques années selon Linus Thorvald).
C’est que Rust doit pas être si mauvais par rapport au C++.
#9.1
Je ne sais pas qui est ce Thorvald, mais j’aimerais bien voir une déclaration de Linus Torvalds disant cela.
En tant que lecteur de ce site, on sait que l’introduction de Rust en tant que second langage de programmation après le C a commencé par des travaux préparatoires.
Mais avant que le Rust remplace tout le code C, ça risque de prendre plus que quelques années.
#9.2
Il n’y a pas de C++ dans le noyau
#9.3
Non seulement il n’y a pas de C++ dans le noyau, comme signalé par plop97 mais en plus il n’a jamais été question de remplacer quoi que ce soit.
L’introduction de Rust dans le noyau consiste uniquement en l’autorisation d’utiliser Rust pour écrire des pilotes. Le cœur restera en C aussi loin qu’on puisse voir (j’ai pas mieux pour “foreseeable future”).
#10
Ah mais purée, les ascenseurs dont parle l’article, ce sont les ascenseurs de défilement dans les programmes, pas les ascenseurs qu’on trouve dans les immeubles
#10.1
Non, ça parle bien des ascenseurs dans les immeubles.
#11
#12
Arf, du C++ dans le noyau!!! Et vu la masse de source concernée, 30 ans de développement en gros, un hypothétique passage à autre chose tout en maintenant l’existant ce serait des décennies.
C’est beau de rêver. Puis intérêt?
#13
Il y a de fortes chances en effet que ce soit codé en C
#14
Note que ça fait très longtemps (plus de 15 ans) que le byte code java est compilé à la volée en langage machine (compilateur JIT - Just In Time), avec un bonne efficacité.
Pour ci-dessus.
Je ne pense pas que ce soit programmé, ce sont des circuits très simples (vu le fonctionnement d’un ascenseur). Probablement une sorte d’ASIC créé sur mesure pour chaque ascenseur.
Bon, pour des ascenseurs modernes avec affichage LCD animé, peut-être un système embarqué avec un peu plus de code.
S’il y a du code, oui. De l’assembleur dans le temps.
PS : ah ben dans l’article, il est dit « The software inside devices like elevators is often written in languages like C++ or C, ».
#15
Si Mozilla pouvais toucher 1 centime par 10aine de $ de revenus généré par Meta et consors grace a leur utilisation de Rust, je suis sur qu’ils seraient bien plus a l’aise financièrement
#16
Pour avoir déjà eu l’occasion de voir l’envers du décor de l’ascenseur de ma résidence (un techos de Schindler très sympa qui m’avait montré), l’informatique ne se trouve quasi pas dans la cabine. C’est dans la porte d’un des étages (dans mon cas le dernier) où il avait ouvert le panneau amovible et dedans il y avait l’ordinateur qui contrôlait l’engin.
#16.1
surement des PLCs, même pas sur que ce soit des cartes dédiées.
Et peut-être codé en grafcet puis convertir en C.
#17
Pour commencer : « drivers are probably the first place for an attempt like this ».
« foreseeable future », ça se traduit par « dans l’avenir proche » (oui, les anglais ne voient pas très loin, à cause du brouillard certainement
).
Mais oui, le cœur en C ne va certainement pas être réécrit en Rust avant un bon moment.
C’est uniquement prévu de l’utiliser pour écrire du nouveau code.
Pour le moment
.
#18
La comparaison me semble pertinente: d’un côté Rust est compilé une fois, de l’autre Java est recompilé à chaque nouvelle exécution. Gain de temps, gain de puissance… gain d’énergie.
D’ailleurs, Microsoft travaille sur de la compilation AOT (Ahead of Time) similaire a Rust pour .Net. Je ne sais pas si ça existe pour Java.
#19
Java n’est pas tant à la remasse que cela question Energy et Time.
Y a que pour la mémoire que c’est un problème (un problème connu).
Bref, quand je pense que tout le monde déploie du node-js…
#19.1
et ne parlons pas du désastre qu’est Python…
En fait pour moi, la grosse surprise c’est les perfs du Pascal… je devrait peut-être m’y remettre, ça a beaucoup évolué en 25 ans?
#19.2
Il manque une colonne facilité d’apprentissage et d’utilisation, là python serait premier haut la main…
#19.3
C’est quoi ce tableau sorti de je ne sais où ?
#19.4
Ça à l’air de venir de là : Energy efficiency across programming languages: how do energy, time, and memory relate?
#20
La publication à utilisé le “Computer Language Benchmarks Game” (CLBG):
https://benchmarksgame-team.pages.debian.net/benchmarksgame/
Le pascal utilisé est donc “Free Pascal”:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/pascal.html
C’est un pascal moderne avec de l’orienté-objet, des génériques… Un peu comme Delphi.
https://fr.wikipedia.org/wiki/Free_Pascal
#21
Ca fait des années qu’on peut compiler du .Net en natif avec l’outil NGen.exe
Pour Java, ça a existé, en version plus ou moins utilisable, par exemple avec gcj ou oracle server accelerator.
En IOT, compiler avant a du sens. En server, c’est moins pertinent: une VM peut passer d’un CPU à un autre et avoir une autre config. Par ailleurs, tous les chemins de code sur une appli ne sont pas parcourus, sur une grosse appli tout compiler n’est pas forcément nécessaire.
Android par exemple compile (compilait?) les applis au démarrage, d’où le temps nécessaire à avoir une tablette utilisable en cas de redémarrage (5 min chez moi :( )
Des expériences existent toujours pour déployer des applis en bytecode (WASM, LLVM) pour protéger la propriété intellectuelle et permettre quand même une optimisation sur la machine destination.
Pour info, des compilateurs avec bytecode intermédiaire existent depuis les années 80 au moins (Pascal en premier il me semble)
Enfin, dans l’IOT, il n’y a pas que du C, beaucoup de choses sont en langage interprété (Basic à l’époque, Lua dans les années 2000, langage propriétaire et parfois javascript)
Ceci vaut aussi pour le “temps réel” car temps réel ne veut pas dire “immédiat avec la plus faible latence” mais “garantie de temps de traitement” - ce qui s’appuie autant sur le logiciel que sur l’OS et la conception même de l’appareil.
#22
Si tout compiler n’est pas nécessaire, c’est peut-être aussi que l’on incorpore trop de choses inutiles.
Reste que chaque démarrage d’application basée sur spring dans un environnement kubernetes pourvu de quotas est comme un magnifique poème débité à toute petite vitesse … Quand ton application a besoin d’un initial delay équivalent à un serveur DB, c’est que c’est du java.
#22.1
ça dépend de ce que tu mets dans ton Java. Il y a quelques années je bossais sur un petit module serveur en Java. C’était du Java basique, sans grosse librairie, où tout était fait plus ou moins à la main (hors logging et cryptographie, de mémoire).
J’avais proposé à mon chef de passer à Spring Boot, parce-que “standard et bien documenté”. Il m’avait demandé combien de temps ça mettrait pour démarrer, j’ai fait un “hello world” en Spring boot.
Résultat : 30s pour le démarrage. Mon module démarrait immédiatement. J’ai juste dit à mon chef qu’on allait rester sur ce qu’on avait.
En pratique, le problème de “perfs Java” n’est pas intrinsèque au langage, il est plutôt causé par la lourdeur des frameworks. Quand tu mets un Spring Boot juste pour pas avoir à gérer les paramètres de ligne de commande, c’est clair que tu utilises un char d’assaut pour tuer un moustique… Le problème, c’est que c’est un peu le réflexe aujourd’hui…
#23
Merci!
J’avais fait pas mal de turbo pascal fin des années 80 et début des années 90 avant de passer à Watcom C++ puis DJGPP, mais j’avais encore occasionnellement utilisé delphi (jusqu’à la version 2). J’essayerai Lazarus à l’occasion…
#24
L’embarqué d’aujourd’hui c’est un esp32 à 2$, qui s’accorde d’une pile bouton pour son alim et qui offre beaucoup plus de puissance, ram et stockage dispo que mon Pentium 1st gen qui faisait tourner un windows 98 complet.
#24.1
Va dire ça à ceux qui font dans l’avionique !
L’embarqué, c’est plein de choses différentes.
#25
C’est une possibilité parmi d’autres, ST, NXP, Microchip et Atmel vendent toujours très bien leurs micro-contrôleurs (enfin NXP un peu moins vu leurs galères de production).
Déjà c’est limite hors spec puisqu’il faut 3V mini et qu’une pile bouton c’est 3V nominaux, donc un peu plus bien chargée et moins passé la mi-charge, et à condition de pas trop tirer dessus en pointe. A mon sens c’est plutôt prévu pour une utilisation avec batterie lithium qui fait quelques centaines de mV de plus (et qui existe aussi au format pile bouton, si c’est de ça dont tu parlais il faudrait le préciser car une pile bouton pour la majorité c’est une batterie non rechargeable censée durer des années).
Ensuite ça dépend ce qu’on fait avec, il faut pouvoir mettre l’ESP en sommeil la très grande majorité du temps, sinon à 30 mA de consommation, la pile bouton va pas durer longtemps. Et si on utilise le WiFi alors on dépasse les 150 mA en pointe et là il faut se contenter d’une ou deux très courtes connexions par jour et espérer que la pointe de consommation ne fera rien planter par manque de tension.
Il y a des puces moins consommatrices que l’ESP si on a aussi peu d’énergie, surtout si on n’a pas besoin de WiFi (qui reste un des gros avantage de l’ESP à mon sens alors que la consommation ne l’est pas).
Puissance faut voir, la fréquence ne fait pas tout, déjà on compare du RISC et du CISC, et apparemment par exemple le FPU des ESP est particulièrement lent. Pour la RAM, on dépassait la dizaine de Mo sur Pentium quand l’ESP a 520 Ko, et le stockage c’était plusieurs dizaines ou centaines de Mo de disque dur quand l’ESP a quelques Mo de flash.
L’ESP32 c’est très bien, mais il ne faut ni exagérer ses capacités ni imaginer qu’il n’existe que ça. Ses gros avantages sont avant tout le prix, la présence des modules radios intégrés, et sa logithèque et compatibilité avec l’écosystème Arduino, mais il a aussi des défauts.
#26
on s’en fout du 3V ou de la pile bouton ; prends un peu de recul.
Ce que je disais c’est qu’on a la puissance d’un ordi desktop de l’époque, dispo désormais dans une puce qui consomme que dalle, ne coûte rien, se produit et s’achète par palettes. Quelle qu’elle soit.
La puissance de traitement pour l’embarqué n’est donc absolument plus un problème dans 99.99% des besoins.
Et donc les comms précédents concernant l’overhead induit par telle techno / langage / framework relèvent du pignolage de geek en manque de duels éculés style Atari vs Amiga.
#27
C’est clair que garder l’application sobre et compacte au lieu de pondre par défaut des machins obèses avec 50 librairies inutiles, ça peut aider.
Je fais de la consultance dans le domaine de l’orchestration kubernetes depuis quelques années, et force est de constater que de nombreux développeurs java que j’ai rencontré utilisent le mot micro-service pour désignes des trucs qui ne font quasi rien mais bouffent 16GiB de ram et consomment 8 cpu… alors oui, sur la fonctionnalité c’est micro, mais pourquoi cette obésité systématique sur l’empreinte.
#28
Pas d’accord, l’impact des frameworks trop gros et des applications inefficaces, je le vis au quotidien.
Quand on vit dans le monde réel et pas sur les terres magiques du royaume de la Théorie, une appli qui surconsomme des ressources, qui explose ses SLA ou qui tape dans ses quotas, ça a son importance. D’ailleurs on voit bien les (bons) développeurs Java qui s’échinent à migrer de plus en plus vers des solutions plus compactes, voir du natif.
Et quand tu dois payer pour le temps cpu dans le cloud publique avec des centaines de microservices, la recherche d’optimisation peut très vite se rentabiliser.
#29
#29.1
Désolé, mais comme c’était un paragraphe séparé, et que la formulation semblait indiquer une grande vérité s’appliquant à toute la terre, je me disais que tu appliquais bien ton “raisonnement” à toutes les discussions précédentes sur les perfs et l’overhead des frameworks, et pas que pour l’embarqué .
Mais bon, après avoir relu ton message et à quoi il répondait, je me dis qu’effectivement en répondant tout le temps “blablabla” au lieu d’un truc argumenté, il y a peut-être effectivement moyen de faire durer ta pible 3 volts longtemps.
#30
ca vient du PDF qui est cité dans la news.
Je vois que personne ne lit vraiment les news, c’est cool…