IdentifiantMot de passe
Mot de passe oubli� ?Je m'inscris ! (gratuit)

Vous �tes nouveau sur Developpez.com ? Cr�ez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et �tre connect� pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Cr�ez-en un en quelques instants, c'est enti�rement gratuit !

Si vous disposez d�j� d'un compte et qu'il est bien activ�, connectez-vous � l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oubli� ?
Cr�er un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

� 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++

Le , par Patrick Ruiz
38 commentaires

143PARTAGES

10  0 
� 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++.



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.



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.)



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.



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.


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.


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
Vous avez lu gratuitement 0 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer � vous proposer des publications.

Une erreur dans cette actualit� ? Signalez-nous-la !

38 commentaires
Commenter Signaler un probl�me
Pyramidev
Avatar de Pyramidev
Expert �minent https://www.developpez.com
Le 30/03/2024 � 20:28
J'avais vu passer �a sur r/rustjerk.

Citation Envoy� par Patrick Ruiz Voir le message
Comment se fait-il que les �quipes qui utilisent Rust soient aussi peu productives que celles qui utilisent Go ?
5  0 
kiruahxh
Avatar de kiruahxh
Nouveau membre du Club https://www.developpez.com
Le 30/03/2024 � 20:50
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
5  0 
Pyramidev
Avatar de Pyramidev
Expert �minent https://www.developpez.com
Le 02/04/2024 � 1:23
Citation Envoy� par Pyramidev Voir le message
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 :

Citation 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.

Citation Envoy� par Metal3d Voir le message
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.
Citation Envoy� par OrthodoxWindows Voir le message
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 ?
3  0 
NotABread
Avatar de NotABread
Membre actif https://www.developpez.com
Le 10/09/2024 � 9:50
Citation Envoy� par 23JFK Voir le message
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)
3  0 
fdecode
Avatar de fdecode
Membre habitu� https://www.developpez.com
Le 13/09/2024 � 22:53
Citation Envoy� par 23JFK Voir le message
Ou que l'on oblig� de faire de l'unsafe et l'unstable.
Et bien non! Il ne vous a pas �chapp� si vous �tes all�s sur le Playground, que le code en question fonctionne dans une version stable de Rust:

Ce qui est nighty, c'est la librairie SIMD, pas les instructions machines r�pliqu�es dans le core Rust.

Pour ce qui est de l'unsafe, il est tout naturellement utilis� ici pour inclure du code machine, donc ext�rieur � Rust, tout comme on utilise de l'unsafe pour inclure une librairie C : cela sert � isoler les parties du code non contr�l�es par la s�mantique de s�curisation de Rust. Il s'agit pour le coup du contexte d'utilisation le plus simple de l'unsafe: d�limiter le code externe. Pas de risque d'UB. Vous ne risqueriez donc pas d'y perdre des dents.
3  0 
Metal3d
Avatar de Metal3d
Membre habitu� https://www.developpez.com
Le 30/03/2024 � 21:13
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.
9  7 
Christophe
Avatar de Christophe
Responsable Syst�mes https://www.developpez.com
Le 01/04/2024 � 18:58
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.
3  1 
imperio
Avatar de imperio
Membre chevronn� https://www.developpez.com
Le 01/04/2024 � 22:49
Citation Envoy� par chrtophe Voir le message
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).
2  0 
fdecode
Avatar de fdecode
Membre habitu� https://www.developpez.com
Le 12/09/2024 � 11:15
Citation Envoy� par 23JFK  Voir le message
Reste qu'apparemment, il n'est pas possible de tout faire en Rust et certain projet comme construire une librairie Rust semble carr�ment impossible, l'algorithme de la racine carr�-inverse rapide ne semble pas non plus pouvoir �tre tol�r�e par le compilateur (sp�culatif, je n'ai pas essay� ; mais �tant donn� qu'il faille jouer avec les diff�rents motifs m�moire fonction du types des nombres, en Rust �a doit �tre un enfer) ; la compilation est affreusement lente quand il faut r�cup�rer tous les paquets Cargo pour un gros projet. Franchement pass� la hype, je ne vois pas comment Rust pourrait avoir une trajectoire diff�rente d'Ocaml ou Haskell, c'est un truc d'universit�/laboratoire qui ne semble pas pouvoir s'adapter � la r�alit� des entreprises.

Cela a l'air tr�s personnels et �motionnels comme griefs. Je vais simplement r�pondre � la demande concr�te de votre message: "algorithme de la racine carr�-inverse rapide" (de quake, je suppose).
Dans la mesure o� c'est un algorithme de calcul tr�s approximatif, et que l'instruction SSE RSQRT existe d�sormais, il me para�t assez peu int�ressant, mais il a quand m�me �t� facile de trouver un exemple d'impl�mentation [playground]:

Code : S�lectionner tout 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
fn inv_sqrt(x: f32) -> f32 { 
    let i = x.to_bits(); 
    let i = 0x5f3759df - (i >> 1); 
    let y = f32::from_bits(i); 
     
    y * (1.5 - 0.5 * x * y * y) 
} 
 
 
fn print_both(v: f32) { 
    println!("quake: {}", inv_sqrt(v)); 
    println!("real:  {}", 1.0 / v.sqrt()); 
    println!(); 
} 
 
fn main() { 
    print_both(4.0); 
    print_both(10.0); 
    print_both(3.1415); 
}
Ceci-dit, le code de quake n'est pas tr�s int�ressant puisque le calcul exact tient en 3 instructions machine.
2  0 
Uther
Avatar de Uther
Expert �minent s�nior https://www.developpez.com
Le 13/09/2024 � 9:48
C'est pour �a que le nombre d'instruction machine n'est pas une m�trique suffisante pour mesurer la performance. Il faut aussi avoir une bonne id�e de l'efficacit� des instructions. Et encore le nombre de cycle d'une instruction peut varier en fonction du contexte.

Les instructions de division et de racines carr�e sont connues pour �tre lentes. Toute l'int�r�t de l�algorithme de Quake, c'est qu'il n'utilise rien de plus complexe que la multiplications.
2  0 
Commenter Signaler un probl�me