Discussion :

[Patrick Ruiz]

« 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

[Pyramidev]

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

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

[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

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

[OrthodoxWindows]

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]

« 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?

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

[imperio]

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]

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 :

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.

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

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

[chrtophe]

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]

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]

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

[fdecode]

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]

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]

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!

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]

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.

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]

« 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 :

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]

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]

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]

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.