Google affirme qu'il est facile de remplacer C/C++ par Rust dans les firmwares

**Patrick Ruiz** · 30/03/2024, 09h53

� Les �quipes Rust chez Google sont deux fois plus productives que celles qui se servent de C++ �, d�apr�s un responsable de l�entreprise
Qui lance le d�bat de la productivit� entre Rust et C++

Les comparatifs entre les langages Rust et C++ portent en g�n�ral sur des aspects comme la performance et la s�curisation des espaces m�moires des applications. Certains benchmarks sugg�rent que les applications Rust sont plus rapides que leurs �quivalents en langage C. Et c�est justement pour ces atouts que sont la parit� en termes de vitesse d�ex�cution en comparaison avec le C, mais surtout pour la s�curisation et la fiabilit� que de plus en plus d�acteurs de la fili�re du d�veloppement informatique recommandent le Rust plut�t que le C ou le C++. C�est sur la question de l�impact que le choix de ces langages a sur la productivit� des d�veloppeurs que les intervenants ne se sont pas trop pench�s. Google vient de publier les r�sultats d�un sondage en interne et il en ressort que les �quipes Rust en son sein sont deux fois plus productives que celles qui se servent du langage C++.

Les conclusions de Google se basent sur les perceptions des r�pondants au sondage. Le temps n�cessaire � une r�impl�mentation en Rust compar� � celui d�une pr�c�dente r�impl�mentation en langage C++ est l�un des premiers aspects sur lesquels le sondage en interne au g�ant technologique a port�.

� Nous avons not� une r�duction de 50 % de l�effort n�cessaire pour mettre sur pied un service en langage Rust ainsi que pour en assurer la maintenance �, d�clare Lars Bergstrom dans son comparatif d�impact sur la productivit� des d�veloppeurs caus� par les langages Rust et C++.

Nom : 1.png
Affichages : 117503
Taille : 330,0 Ko

L�enqu�te comparative de l�impact du choix des langages C++ et Rust sur la productivit� des d�veloppeurs s�est �tendue au-del� de la production du code informatique. Les r�pondants ont en sus partag� leurs perceptions pour ce qui est de la productivit� en Rust compar�e � celle d�autres langages (C++, Java, etc.) dont ils font usage. Dans les chiffres, le tiers des r�pondants a d�clar� devenir aussi productif en Rust que dans les autres langages en 2 mois au maximum.

Nom : 2.png
Affichages : 25384
Taille : 136,4 Ko

Lorsqu'un d�veloppeur a fini de travailler sur un ticket, un autre membre de son �quipe passe en revue le code en se posant les questions suivantes :

Le code pr�sente-t-il des erreurs logiques �videntes ?
Apr�s examen des exigences, tous les cas ont-ils �t� compl�tement mis en �uvre ?
Les nouveaux tests automatis�s sont-ils suffisants pour le nouveau code ? Les tests automatis�s existants doivent-ils �tre r��crits pour int�grer les modifications apport�es au code ?
Le nouveau code est-il conforme au guide stylistique actuel ?

C�est un jeu de questions qui d�montre le potentiel impact des revues de code sur la productivit� d�un ou d�une �quipe enti�re de d�veloppement. Les r�sultats de l�enqu�te de Google sugg�rent que le langage Rust est susceptible de s�av�rer �tre un bon choix pour ceux d�sireux de se simplifier les revues de code. En effet, plus de la moiti� des r�pondants du sondage d�clarent que les revues de code en langage Rust sont plus ais�es que dans d�autres langages (C++, Java, Python, etc.)

Nom : 3.png
Affichages : 25287
Taille : 116,7 Ko

Le sondage s�est en sus pench� sur la qualit� du code comme indicateur de productivit�. Dans les chiffres, 85 % des r�pondants sont d�avis que le langage Rust permet d�obtenir des bases de code d�un niveau de qualit� sup�rieur � celui d�autres langages.

Nom : 4.png
Affichages : 25229
Taille : 115,7 Ko

L�analyse du temps pass� par les d�veloppeurs de logiciels dans les activit�s de cr�ation de produits et les t�ches n�cessaires pour mettre le code en production fait partie des m�triques sur lesquelles s�appuie McKinsey dans l��valuation de la productivit� des d�veloppeurs. De fa�on concr�te, il s�agit de mesurer la r�partition du temps entre les activit�s de codage, de construction et de tests unitaires (boucle interne) et les activit�s d�int�gration, de test d�int�gration, de publication et de d�ploiement (boucle externe). C�est la mise en �uvre d�un proc�d� en principe similaire qui permet � Google d�arriver � la conclusion que les �quipes Rust chez Google sont deux fois plus productives que celles qui s�appuient sur le langage C++.

La productivit� des d�veloppeurs est en g�n�ral sujette � d�bats. Certains intervenants de la fili�re sont d�avis que le sondage de Google souffre d�un biais de s�lection des r�pondants dont les perceptions orientent les r�sultats.

Nom : 5.png
Affichages : 25073
Taille : 27,0 Ko

Certains intervenants de la fili�re mettent souvent la cha�ne d�outils du langage Rust en avant comme l�un des atouts susceptibles d�am�liorer la productivit� des d�veloppeurs en comparaison � d�autres langages de programmation. Des observateurs sont n�anmoins d�avis que le compilateur Rust est un tueur silencieux de la productivit� des d�veloppeurs qui travaillent sur des bases de code importantes.

Nom : 6.png
Affichages : 25103
Taille : 90,5 Ko

Source : Lars Bergstrom

Et vous ?

Quelle appr�ciation faites-vous des r�sultats de ce sondage men� en interne par Google ? Sont-ils pertinents ? Quels sont les aspects qui vous semblent biais�s ?

Que pensez-vous de l�analyse du temps pass� en C++ puis en Rust dans les activit�s de cr�ation de produits et les t�ches n�cessaires pour mettre le code en production comme m�trique de mesure de la productivit� des d�veloppeurs ? Quelles sont les m�triques susceptibles de la compl�ter dans le processus de comparaison de l�impact du choix des langages C et C++ sur la productivit� des d�veloppeurs ?

Voir aussi :

Programmation : une �tude r�v�le les langages les plus voraces en �nergie, Perl, Python et Ruby en t�te, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avanc�e du langage Rust dans le d�veloppement du noyau Linux, et aurait qualifi� le C++ de � langage de m... �, apr�s le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour cr�er la Fondation Rust, une organisation � but non lucratif charg�e de g�rer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son �quipe Rust par des nouveaux talents

**Pyramidev** · 30/03/2024, 20h28

J'avais vu passer �a sur r/rustjerk.

Envoy� par Patrick Ruiz

Comment se fait-il que les �quipes qui utilisent Rust soient aussi peu productives que celles qui utilisent Go ?

**kiruahxh** · 30/03/2024, 20h50

Le gros soucis de productivit� en C++ vient de la cha�ne d'outils (gestion des d�pendances, scripts de build, cross-compilation) et de la librairie standard, tr�s optimis�e mais pauvre en fonctionnalit�s. Avec le framework Qt on se sent d�j� un peu mieux.
Je pense que ces soucis peuvent bien prendre la moiti� du temps de dev, le langage lui-m�me �tant assez complet pour du bas niveau

**Metal3d** · 30/03/2024, 21h13

Les dev Rust s'admirent tellement dans le miroir. Franchement, le comportement de leur communaut� me d�cide � ne plus jamais utiliser Rust. Ils sont devenus hautains, d�sagr�ables, insultant et surtout ils utilisent des arguments moisis pour descendre les autres langages. �a me d�go�te au point de rejeter leur langage malgr� l'int�r�t potentiel du compilo (c'est le seul truc bien de Rust d'ailleurs)

Moi j'en ai marre de les entendre.

**OrthodoxWindows** · 30/03/2024, 21h41

Envoy� par Metal3d

Les dev Rust s'admirent tellement dans le miroir. Franchement, le comportement de leur communaut� me d�cide � ne plus jamais utiliser Rust. Ils sont devenus hautains, d�sagr�ables, insultant et surtout ils utilisent des arguments moisis pour descendre les autres langages. �a me d�go�te au point de rejeter leur langage malgr� l'int�r�t potentiel du compilo (c'est le seul truc bien de Rust d'ailleurs)

Moi j'en ai marre de les entendre.

Pourtant Rust poss�de de nombreuses qualit�s ind�niables, mais il n'est en effet pas aid� par sa communaut�.
Le m�pris des autres n'incite pas � la consid�ration...

**Anselme45** · 01/04/2024, 10h07

� Les �quipes Rust chez Google sont deux fois plus productives que celles qui se servent de C++ �, d�apr�s un responsable de l�entreprise

Est-il utile de pr�ciser que Google est un membre fondateur de la RUST Fondation?

**Christophe** · 01/04/2024, 18h58

Non,

C'est Mozilla qui a tout d'abord parrain� Rust qui a �t� cr�� par un de leur ing�nieur. Microsoft en est membre �galement.

Google on cr�� Go, mais c'est sur Rust qu'ils investissent.

**imperio** · 01/04/2024, 22h49

Envoy� par chrtophe

Non,

C'est Mozilla qui a tout d'abord parrain� Rust qui a �t� cr�� par un de leur ing�nieur. Microsoft en est membre �galement.

Google on cr�� Go, mais c'est sur Rust qu'ils investissent.

Ce qu'a dit Anselme45 est juste, Google est bien un des membres fondateurs de la fondation Rust (qui a �t� cr��e quand Mozilla a arr�t� de supporter le projet).

Ceci dit, Google est une �norme entreprise, donc placer de l'argent dans Rust ne les emp�che pas de supporter d'autres projets (comme Go).

**Pyramidev** · 02/04/2024, 01h23

Envoy� par Pyramidev

Comment se fait-il que les �quipes qui utilisent Rust soient aussi peu productives que celles qui utilisent Go ?

J'avais �crit ce passage sur un ton un peu trollesque, car j'aime bien taper sur le langage Go de temps en temps. La derni�re fois, je crois que c'�tait en juillet 2023.

Concernant la conf�rence, je viens de regarder ce qui en a �t� dit sur r/rust. Je suis tomb� sur le commentaire :

Envoy� par steveklabnik1

For everyone asking: in the talk, Lars mentions that they often rely on self-reported anonymous data. But in this case, Google is large enough that teams have developed similar systems and/or literally re-written things, and so this claim comes from analyzing projects before and after these re-writes, so you�re comparing like teams and like projects. Timestamped: https://youtu.be/6mZRWFQRvmw?t=27012

Some additional context on these two specific claims:

Google found that porting Go to Rust "it takes about the same sized team about the same time to build it, so that's no loss of productivity" and "we do see some benefits from it, we see reduced memory usage [...] and we also see a decreased defect rate over time"

On re-writing C++ into Rust: "in every case, we've seen a decrease by more than 2x in the amount of effort required to both build the services written in Rust, as well as maintain and update those services. [...] C++ is very expensive for us to maintain."

� 7h30m12, il y a effectivement des d�tails int�ressants.

En fait, le pr�sentateur ne dit pas que la r��criture en Rust offre la m�me productivit� que l'�criture en Go. Il dit que l'�quipe a la m�me taille et que �a prend autant de temps � coder, mais aussi que �a r�duit la consommation de m�moire et les bogues. Moins de bogues, ce n'est pas une productivit� �gale.

Envoy� par Metal3d

Les dev Rust s'admirent tellement dans le miroir. Franchement, le comportement de leur communaut� me d�cide � ne plus jamais utiliser Rust. Ils sont devenus hautains, d�sagr�ables, insultant et surtout ils utilisent des arguments moisis pour descendre les autres langages. �a me d�go�te au point de rejeter leur langage malgr� l'int�r�t potentiel du compilo (c'est le seul truc bien de Rust d'ailleurs)

Moi j'en ai marre de les entendre.

Envoy� par OrthodoxWindows

Pourtant Rust poss�de de nombreuses qualit�s ind�niables, mais il n'est en effet pas aid� par sa communaut�.
Le m�pris des autres n'incite pas � la consid�ration...

Est-ce sp�cifiquement sur ce forum ou bien aussi ailleurs ?

**Christophe** · 02/04/2024, 07h17

Ce qu'a dit Anselme45 est juste

Je me suis mal exprim�. Je voulais dire que non, il n'�tait pas utile de pr�ciser que Google est membre fondateur de la Rust Foundation.

C'est pas parce qu'ils financent Rust que leurs �quipes sont deux fois plus productives qu'en utilisant C++.

**walfrat** · 02/04/2024, 10h08

Envoy� par Metal3d

Les dev Rust s'admirent tellement dans le miroir. Franchement, le comportement de leur communaut� me d�cide � ne plus jamais utiliser Rust. Ils sont devenus hautains, d�sagr�ables, insultant et surtout ils utilisent des arguments moisis pour descendre les autres langages. �a me d�go�te au point de rejeter leur langage malgr� l'int�r�t potentiel du compilo (c'est le seul truc bien de Rust d'ailleurs)

Moi j'en ai marre de les entendre.

Est ce que tu es sur qu'il s'agissent vraiment de dev Rust pur et dur ? Et pas de devs qui suivent les modes en trouvant toujours une excuse pour degueuler sur un truc d�s que la mode est pass�e ?

Parce que bon, des gens qui vomissent et pr�tendent que tel truc est "dead" c'est pas nouveau

**djm44** · 03/04/2024, 00h21

Avec Rust l'homme d�passe la machine dans la course � la productivit�.

**fdecode** · 03/04/2024, 14h53

Envoy� par kiruahxh

Le gros soucis de productivit� en C++ vient de la cha�ne d'outils (gestion des d�pendances, scripts de build, cross-compilation) et de la librairie standard, tr�s optimis�e mais pauvre en fonctionnalit�s. Avec le framework Qt on se sent d�j� un peu mieux.
Je pense que ces soucis peuvent bien prendre la moiti� du temps de dev, le langage lui-m�me �tant assez complet pour du bas niveau

Je confirme que c'est l'une des qualit�s de Rust qui le rendent agr�able pour le d�veloppement: l'�cosyst�me constitu� autour du d�p�t crates.io et de l'utilitaire de build et de gestion des d�pendances, `cargo`, est l'un des atouts du langage.

La librairie standard de Rust au sens strict reste relativement concise.
Mais de nombreuses fonctionnalit�s sont importables depuis crates.io, avec derri�re une communaut� qui soutient le d�veloppement de rust. Par exemple:

macros proc�durales (fonctionnalit� tr�s puissante notamment pour les capacit�s de programmation g�n�rique) par analyse de l'arbre syntaxique: proc-macro2 ; syn ; quote
s�rialisation g�n�rique: serde
runtimes pour programmation asynchrone: tokio ; async-std ; ...
g�n�rateurs de nombres al�atoires: rand ; rand_distr (pas de g�n�rateur de nombre al�atoire dans std si ce n'est certaines capacit�s sp�cifiques aux architectures; cela m'avait surpris au d�but)
types num�riques: num
alg�bre lin�aire/multilin�aire: nalgebra ; faer ; ndarray
etc.

En d�finitive, il se constitue une sorte de continuum entre la librairie standard et les efforts de d�veloppement individuels en passant par des librairies qu'on pourrait qualifier de quasi-standard. Tout cela est rendu coh�rent gr�ce au site de d�p�t, crates.io, et � l'outil `cargo`, qui fait un contr�le par compilation de toutes les librairies soumises sur le site de d�p�t.

**fdecode** · 03/04/2024, 15h05

Envoy� par Anselme45

Est-il utile de pr�ciser que Google est un membre fondateur de la RUST Fondation?

Rust est un langage cr�� chez Mozilla (2006-2019). Il a notamment servi � d�velopper le moteur de recherche exp�rimental servo, qui a �t� abandonn� par Mozilla et r�cup�r� par la Linux Foundation.

La fondation Rust s'est constitu�e lorsque Mozilla s'est d�sengag� de certains de ses projets de recherche, dont servo et Rust (2020). Les membres fondateurs sont: Mozilla, amazon, google, huawei et microsoft

Il est donc � noter que les principaux financeurs (membres platinum) de la rust foundation, amazon, google, meta, huawei et microsoft, ne sont pas � l'origine de la cr�ation de ce langage.

**fdecode** · 03/04/2024, 15h32

Envoy� par Metal3d

Franchement, le comportement de leur communaut� me d�cide � ne plus jamais utiliser Rust. Ils sont devenus hautains, d�sagr�ables, insultant et surtout ils utilisent des arguments moisis pour descendre les autres langages. �a me d�go�te au point de rejeter leur langage malgr� l'int�r�t potentiel du compilo (c'est le seul truc bien de Rust d'ailleurs)

Moi j'en ai marre de les entendre.

Je ne peux que vous conseiller de continuer selon vos d�sirs!

Envoy� par Metal3d

Les dev Rust s'admirent tellement dans le miroir

Non, je pense qu'ils admirent avant tout le langage et qu'ils lui sont reconnaissants de les aider � bien programmer. Et le langage lui-m�me h�rite de quelques beaux concepts qui ont m�ri au fil du temps.

Cet article un peu dat� est assez �clairant sur quelques belles id�es dont Rust s'est inspir�:
https://pling.jondgoodwin.com/post/cyclone/

**St�phane le calme** · 09/09/2024, 22h18

Google affirme qu'il est non seulement possible, mais aussi relativement facile de remplacer C/C++ par Rust dans les firmwares
L'entreprise explique en quoi ce changement est avantageux

Dans le monde de la programmation, les langages C et C++ ont longtemps domin� le d�veloppement de firmware. Cependant, Google a r�cemment fait une d�claration audacieuse : remplacer ces langages par Rust serait non seulement possible, mais aussi relativement facile.

Pourquoi Rust ?

Rust est un langage de programmation qui a gagn� en popularit� gr�ce � ses caract�ristiques de s�curit� et de performance. Contrairement � C et C++, Rust offre une gestion de la m�moire plus s�re, r�duisant ainsi les risques de bugs tels que les d�passements de tampon et les erreurs de lib�ration de m�moire. Ces probl�mes sont souvent � l�origine de vuln�rabilit�s critiques dans les syst�mes logiciels.

C'est d'ailleurs cet aspect s�curitaire que Google met en avant :

� Les microprogrammes servent d'interface entre le mat�riel et les logiciels de niveau sup�rieur. En raison de l'absence de m�canismes de s�curit� standard dans les logiciels de niveau sup�rieur, les vuln�rabilit�s du code des microprogrammes peuvent �tre dangereusement exploit�es par des acteurs malveillants. Les t�l�phones modernes contiennent de nombreux coprocesseurs charg�s de g�rer diverses op�rations, et chacun d'entre eux ex�cute son propre microprogramme. Souvent, les microprogrammes sont constitu�s d'importantes bases de code h�rit�es du pass�, �crites dans des langages peu s�rs pour la m�moire, tels que le C ou le C++. Le manque de s�curit� de la m�moire est la cause principale des vuln�rabilit�s d'Android, de Chrome et de nombreuses autres bases de code.

� Rust offre une alternative au C et au C++ sans risque pour la m�moire, avec des performances et une taille de code comparables. En outre, il prend en charge l'interop�rabilit� avec le C sans surcharge. L'�quipe Android a d�j� discut� de Rust pour les firmwares bare-metal et a d�velopp� une formation sp�cifique pour ce domaine �.

L'initiative de Google

Google a r�cemment r��crit le firmware des machines virtuelles prot�g�es dans son Android Virtualization Framework en utilisant le langage de programmation Rust et souhaite que vous fassiez de m�me, � condition que vous vous occupiez de firmware.

Dans un article publi� jeudi, les ing�nieurs d'Android Ivan Lozano et Dominik Maier se penchent sur les d�tails techniques du remplacement du code C et C++ par le langage Rust. � Vous verrez � quel point il est facile de renforcer la s�curit� avec des remplacements Rust, et nous d�montrerons m�me comment la cha�ne d'outils Rust peut g�rer des cibles sp�cialis�es bare-metal �, ont d�clar� Lozano et Maier.

Facile n'est pas un terme que l'on entend g�n�ralement � propos d'un langage de programmation connu pour sa courbe d'apprentissage abrupte. Il n'est pas non plus facile d'amener les d�veloppeurs C et C++ � voir le monde avec des lentilles teint�es de Rust.

Quoiqu'il en soit, Google opte pour une adoption incr�mentale :

� Notre approche incr�mentale, qui se concentre sur le remplacement du nouveau code et du code existant le plus risqu� (par exemple, le code qui traite des donn�es externes non fiables), permet d'obtenir un maximum d'avantages en mati�re de s�curit� avec un minimum d'efforts. Le simple fait d'�crire tout nouveau code en Rust r�duit le nombre de nouvelles vuln�rabilit�s et, au fil du temps, peut conduire � une r�duction du nombre de vuln�rabilit�s existantes.

� Vous pouvez remplacer une fonctionnalit� C existante en �crivant un shim Rust fin qui fait la traduction entre une API Rust existante et l'API C attendue par la base de code. L'API C est reproduite et export�e par le shim pour que la base de code existante puisse s'y r�f�rer. Le shim sert d'enveloppe � l'API de la biblioth�que Rust, en faisant le lien entre l'API C existante et l'API Rust. Il s'agit d'une approche courante lors de la r��criture ou du remplacement de biblioth�ques existantes par une alternative Rust �.

L'entreprise a �galement une vision quant au choix d'un composant � remplacer :

� Lors du choix d'un composant � remplacer, il convient de privil�gier les composants autonomes qui font l'objet de tests rigoureux. Id�alement, la fonctionnalit� du composant peut �tre fournie par une impl�mentation open-source facilement disponible qui supporte les environnements bare-metal.

� Les analyseurs qui g�rent des formats de donn�es ou des protocoles standard et couramment utilis�s (tels que XML ou DNS) sont de bons candidats initiaux. Cela garantit que l'effort initial se concentre sur les d�fis de l'int�gration de Rust avec la base de code et le syst�me de construction existants plut�t que sur les particularit�s d'un composant complexe et simplifie les tests. Cette approche facilite l'introduction ult�rieure de Rust �.

Les d�fis de la transition

Malgr� les avantages, la transition vers Rust n�est pas sans d�fis. L�un des principaux obstacles est la r�sistance des d�veloppeurs exp�riment�s en C et C++ � adopter un nouveau langage. De plus, Rust est connu pour sa courbe d�apprentissage abrupte, ce qui peut d�courager certains programmeurs.

Il y a quelques jours, l'un des responsables du projet Rust pour Linux - cr�� pour int�grer le code Rust dans le noyau Linux bas� sur le langage C - a d�missionn�, invoquant la r�sistance des d�veloppeurs du noyau Linux.

� Vous n'allez pas nous forcer � apprendre Rust �, a d�clar� un contributeur du noyau Linux lors d'une discussion anim�e au d�but de l'ann�e � l'occasion d'une conf�rence.

Rendez-vous � 28:40

N�anmoins, Google encourage ceux qui le souhaitent � le faire. Citant le manque de m�canismes de s�curit� de haut niveau dans les microprogrammes, qui sont souvent �crits dans des langages peu s�rs pour la m�moire tels que C ou C++, Lozano et Maier affirment que Rust offre un moyen d'�viter les bogues de s�curit� de la m�moire tels que les d�bordements de m�moire tampon et l'utilisation apr�s la lib�ration qui repr�sentent la majorit� des vuln�rabilit�s importantes dans les grandes bases de code.

� Rust offre une alternative au C et au C++ en mati�re de s�curit� de la m�moire, avec des performances et une taille de code comparables �, notent-ils. � En outre, il prend en charge l'interop�rabilit� avec le C sans surco�t.

Nom : deux.png
Affichages : 58944
Taille : 373,2 Ko

Le gouvernement am�ricain recommande Rust � la place de C/C++

Le gouvernement am�ricain a r�cemment insist� sur ce th�me, avec le soutien d'entreprises technologiques de premier plan et d'initiatives � but non lucratif visant � r��crire en Rust des projets et des composants open source essentiels. L'ann�e derni�re, l'Agence pour la cybers�curit� et la s�curit� des infrastructures (Cybersecurity & Infrastructure Security Agency) a recommand� aux fournisseurs de logiciels de � faire de la r�duction et de l'�limination des vuln�rabilit�s li�es � la s�curit� de la m�moire dans leurs gammes de produits un objectif d'entreprise de premier plan �.

Google �tait d�j� convaincu par l'id�e, ayant conclu que ses d�veloppeurs Rust sont deux fois plus productifs que ses ing�nieurs C++.

� Nous reconnaissons le r�le essentiel de Rust dans la construction de logiciels s�rs et fiables � tous les niveaux de la pile �, a d�clar� Lars Bergstrom, directeur de l'ing�nierie pour les langages de programmation Android chez Google et pr�sident du conseil d'administration de la Rust Foundation.

� Chez Google, nous augmentons l'utilisation de Rust dans Android, Chromium, et plus encore, afin de r�duire les vuln�rabilit�s li�es � la s�curit� de la m�moire. Nous sommes d�termin�s � collaborer avec l'�cosyst�me Rust pour favoriser son adoption et fournir aux d�veloppeurs les ressources et la formation dont ils ont besoin pour r�ussir. Ce travail sur l'int�gration de Rust dans les syst�mes embarqu�s et les microprogrammes porte sur une autre partie essentielle de la pile �.

Conclusion

La d�claration de Google sur la facilit� de remplacer C et C++ par Rust dans le firmware est une �tape importante vers une programmation plus s�re et plus efficace. Bien que la transition puisse �tre difficile, les avantages � long terme en termes de s�curit� et de productivit� sont ind�niables. Pour les entreprises technologiques, adopter Rust pourrait bien �tre la cl� pour d�velopper des logiciels plus robustes et s�curis�s.

Source : Google

Et vous ?

Quels sont les avantages et les inconv�nients que vous voyez dans l�utilisation de Rust par rapport � C et C++ ?

Pensez-vous que la courbe d�apprentissage de Rust est un obstacle majeur pour son adoption g�n�ralis�e ? Pourquoi ou pourquoi pas ?

Comment �valuez-vous l�impact de la s�curit� m�moire de Rust sur la qualit� globale du code ?

Avez-vous des exp�riences personnelles ou des anecdotes sur la transition d�un projet de C/C++ � Rust ?

Quels types de projets ou d�industries b�n�ficieraient le plus de l�adoption de Rust selon vous ?

Comment les entreprises peuvent-elles encourager leurs d�veloppeurs � apprendre et � adopter Rust ?

Voyez-vous des domaines o� C et C++ resteraient indispensables malgr� les avantages de Rust ?

Quels outils ou ressources recommanderiez-vous pour apprendre Rust efficacement ?

**Pyramidev** · 09/09/2024, 23h30

Envoy� par St�phane le calme

� Vous n'allez pas nous forcer � apprendre Rust �, a d�clar� un contributeur du noyau Linux lors d'une discussion anim�e au d�but de l'ann�e � l'occasion d'une conf�rence.

Rendez-vous � 28:40

Non seulement il ne veut pas apprendre Rust, mais il est aussi contre le fait d'encoder les r�gles d'usage d'une API directement dans le syst�me de types. Dans le cas o� les r�gles changent, il dit, � 27m23 : "If that breaks Rust, we will find out whether or not this concept of encoding huge amounts of semantics into the type system is a good thing or a bad thing and instead of trying to convince us what is actually correct, let's see what happens in a year or two" (� 27m23).

Le 21 juin, Jake Edge a bien r�sum� cette vid�o dans son article Rust for filesystems.

Le 31 ao�t, sur Mastodon, Asahi Lina a bien expliqu� l'int�r�t d'encoder les r�gles d'usage d'une API dans le syst�me de types :

Envoy� par Asahi Lina

I think people really don't appreciate just how incomplete Linux kernel API docs are, and how Rust solves part of the problem.

I wrote a pile of Rust abstractions for various subsystems. For practically every single one, I had to read the C source code to understand how to use its API.

Simply reading the function signature and associated doc comment (if any) or explicit docs (if you're lucky and they exist) almost never fully tells you how to safely use the API. Do you need to hold a lock? Does a ref counted arg transfer the ref or does it take its own ref?

When a callback is called are any locks held or do you need to acquire your own? What about free callbacks, are they special? What's the intended locking order? Are there special cases where some operations might take locks in some cases but not others?

Is a NULL argument allowed and valid usage, or not? What happens to reference counts in the error case? Is a returned ref counted pointer already incremented, or is it an implied borrow from a reference owned by a passed argument?

Is the return value always a valid pointer? Can it be NULL? Or maybe it's an ERR_PTR? Maybe both? What about pointers returned via indirect arguments, are those cleared to NULL on error or left alone? Is it valid to pass a NULL ** if you don't need that return pointer?

[�]

To be clear, I don't blame Linux developers for the incomplete docs. For better or worse, the Linux kernel is very complex and has to deal with a lot of subtlety. Most userspace APIs have much simpler rules you have to follow to use them safely. Kernels are hard!

Even experienced kernel developers get these things wrong all the time. It's not a skill issue. It's simply not possible for humans to keep all of these complex rules in their head and get them right, every single time. We are not built for that.

We need tooling to help us.

Mais il y a de la r�sistance au changement.

**23JFK** · 10/09/2024, 08h56

Il semble que Rust soit trop strict pour �tre viable dans la cha�ne de d�veloppement d'une entreprise qui vise, entre autre, le profit. Le code permis par Rust est un sous-ensemble de tous les codes fiables et s�curis�s possibles pour un probl�me donn�. Les dev passeraient ainsi plus de temps � se battre avec le compilateur pour satisfaire � toutes les exigences de Rust qu'� �crire d'autres parties de code permettant de livrer dans les temps un produit "fini" (qui fait au moins ce pourquoi il a �t� pr�vu - Osef des bugs, les updates c'est fait pour les corriger) aux utilisateurs. Et de toute fa�on Rust ne permet pas de se pr�munir contre les bugs/failles hardware comme celles qui ont affect� les processeurs Intel (DownFall etc...)

Quant � l'histoire de l'interop�rabilit� avec C/C++ de Rust... Sur le papier peut-�tre, mais en pratique, les d�veloppeurs Rust qui viennent se greffer sur un projet C/C++ demandent aux dev C/C++ de leur faire des interfaces r�pondant aux crit�res Rust et donc de fait, d'apprendre Rust... Euh... dans le monde r�el, c'est plut�t le job de l'outsider de se tirer les doigts du cul pour construire les outils qui lui manquent.

**NotABread** · 10/09/2024, 09h50

Envoy� par 23JFK

Il semble que Rust soit trop strict pour �tre viable dans la cha�ne de d�veloppement d'une entreprise qui vise, entre autre, le profit. Le code permit par Rust est un sous-ensemble de tous les codes fiables et s�curis�s possibles pour un probl�me donn�. Les dev passeraient ainsi plus de temps � se battre avec le compilateur pour satisfaire � toutes les exigences de Rust qu'� �crire d'autres parties de code permettant de livrer dans les temps un produit "fini" (qui fait au moins ce pourquoi il a �t� pr�vu - Osef des bugs, les updates c'est fait pour les corriger) aux utilisateurs. Et de toute fa�on Rust ne permet pas de se pr�munir contre les bugs/failles hardware comme celles qui ont affect� les processeurs Intel (DownFall etc...)

Je ne suis pas d'accord. Je trouve que le fait que le compilateur soit plus strict ne ralenti pas le d�veloppement, car entre le moment o� tu ponds ton premier binaire et le moment o� tu as un binaire pr�s pour la release, et bien tu as des phases de test m�me minime. Donc certes, tu mettras plus de temps � satisfaire ce tyran de compilateur, mais tu gagneras en vas-et-viens entre la plateforme de test et ton PC car toutes les erreurs de manipulation de la m�moire sont �limin� avant m�me que les binaires soient mis sur la plateforme.

Apr�s, Rust, c'est pas magique, tu auras toujours des probl�mes de pr�cision li� � la repr�sentation num�rique, dead lock et autre probl�me classique qui n'est pas en relation avec l'allocation, l'initialisation, la lecture, l'�criture et la lib�ration de la m�moire. De plus, si la majorit� du code doit �tre en unsafe, Rust ne serait pas adapt� (pas assez de connaissance sur les microcontroleurs et firmware pour savoir dans quel sc�nario �a arrive)

**fdecode** · 12/09/2024, 09h11

Envoy� par NotABread

Je ne suis pas d'accord. Je trouve que le fait que le compilateur soit plus strict ne ralenti pas le d�veloppement, car entre le moment o� tu ponds ton premier binaire et le moment o� tu as un binaire pr�s pour la release, et bien tu as des phases de test m�me minime. Donc certes, tu mettras plus de temps � satisfaire ce tyran de compilateur, mais tu gagneras en vas-et-viens entre la plateforme de test et ton PC car toutes les erreurs de manipulation de la m�moire sont �limin� avant m�me que les binaires soient mis sur la plateforme.

D'autant plus qu'on finit par coder du code compilable par Rust beaucoup plus rapidement une fois acquis certains r�flexes.