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 !

Linus Torvalds exprime sa déception de voir le faible taux d'adoption de Rust comme langage de programmation pour le noyau Linux,
Car les principaux mainteneurs du noyau sont plus habitués au langage C

Le , par Patrick Ruiz
26 commentaires

211PARTAGES

10  0 
Après plus de 30 ans, un deuxième langage a fait l’objet d’adoption pour le développement du noyau Linux : le Rust. Linus Torvalds vient de faire un bref état des lieux en termes d’adoption après une année : le taux d’adoption de Rust comme langage de programmation pour le noyau Linux reste faible. Le créateur de Linux a exprimé sa déception à ce propos étant donné qu’il a déjà pris position sur le sujet en soulignant que Rust est une solution pour éviter au noyau Linux et aux mainteneurs de plonger dans la stagnation.

« Je m'attendais à ce que les mises à jour [de la base de code vers Rust] soient plus rapides, mais une partie du problème réside dans le fait que les développeurs de noyau de longue date sont habitués au C et ne connaissent pas Rust. Ils ne sont pas vraiment enthousiastes à l'idée de devoir apprendre un nouveau langage qui est, à certains égards, très différent. Il y a donc eu des réactions négatives à l'égard de Rust », indique-t-il lors du dernier sommet de la Fondation Linux dédié à l’Open Source.



C’est une posture compréhensible quand on se souvient que Linus Torvalds est d’avis que Rust est une solution d’avenir pour le développement du noyau Linux

La prise en charge de Rust pour le développement du noyau Linux est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

De plus, 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++.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.



Les mainteneurs pointent des raisons additionnelles comme l’instabilité de l’infrastructure Rust comme raison de poursuivre avec le C

Greg Kroah-Hartman, le mainteneur du noyau stable, a dit qu’il n’était pas opposé à l’idée d’une branche Rust, mais qu’il faudrait qu’elle soit maintenue par quelqu’un d’autre que lui. Il a aussi demandé comment le code Rust serait testé, et s’il y aurait des outils pour vérifier la qualité du code et la conformité aux normes de codage du noyau. Ojeda a répondu qu’il y avait déjà des outils pour le formatage...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

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

26 commentaires
Commenter Signaler un problème
NotABread
Avatar de NotABread
Membre actif https://www.developpez.com
Le 26/08/2024 à 16:27
@23JFK Qu'est-ce qui fait vieux/dégueulasse dans la syntaxe Rust ? As-tu un exemple que tu considères plus modern/exemplaire ?
5  0 
NotABread
Avatar de NotABread
Membre actif https://www.developpez.com
Le 26/08/2024 à 13:45
> Quels sont les avantages et les inconvénients de Rust par rapport au C pour le code du noyau ?
Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
La sécurité de la mémoire et de la concurrence garanti à la compilation et sans ramasse-miette est LE point fort de Rust. Cependant, Rust reste relativement jeune et son écosystème manque de maturité (lib parfois incompatible entre elle à cause du multithreading, grosse tendance à la sur-inclusion de dépendances, beaucoup en version 0.x, pas encore de framework UI qui se soit démarqué, ...)
C ne sera pas mis au placard par Rust dans la prochaine décennie au sein de Linux pour une simple: Linux est majoritaire écrit en C et le restera car aucun ne veut tout ré-écrire en Rust.

> Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
En théorie, on peut faire du code sûr en C, en pratique cela demande beaucoup d'effort et d'attention. Le monde est vaste et complexe, il y aura toujours un pour trouver un scénario tordu auquel le développeur n'aura pas pensé et qui causera une mauvaise manipulation de la mémoire. Même pour opensshd, logiciel solide et exemplaire, on a trouvé un scénario menant à une mauvaise manipulation de mémoire.
Il est facile de blâmer les développeurs mais ils restent humain, soumis à la fatigue, aux deadlines et aux ressources limités. L'usage d'un langage garantissant sûreté de la mémoire et performance permet de combler le manque d'attention ou de forcer la main sur les problèmes mémoires.

> Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?
Pour l'UEFI, BIOS, driver et microcode, oui, cela fera sense car se sont des parties critiques pour un OS, mais aussi parce que sont des programmes très isolé du reste en dehors de ce qu'ils exposent.
Pour des logiciels plus orienté utilisateur (tableur, logiciel de peinture, calculatrice, ...), non car tant que la haute performance et la stabilité ne sont pas primordiales (et que l'écosystème de Rust ne sera pas mature) il n'y a pas de raison à privilégier python ou un kit webapps à Rust
4  0 
floyer
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 27/08/2024 à 2:58
Lambda calcul avec closure, tuples… ce sont des éléments de sémantique, pas de syntaxe. (La syntaxe c’est plutôt le choix des accolades, begin/end, parentheses…). Et ce n’est pas parce que le lambda calcul ou les tuples (proposé par Python d’ailleurs) datent de 1958 avec Lisp que c’est une mauvaise chose.

Les types… comment un langage peut être sûr en vérifiant la cohérence à la compilation des types sans cela ? Et côté performance, il faut bien des types statiques comme en C. Non je ne vois pas où est le procès.

Le typage dynamique (Lisp, Python, Javascript…) c’est bien pour des scripts, du prototypage… dès que l’on fait des choses plus sérieuses, le typage statique (Typescript…) s’impose, et dans les langages assez modernes, l’inference de type évite que ce soit trop une gêne.

En quoi let est redondant… il indique la déclaration d’une variable par opposition a une affectation qui ne marche qu’avec des variables déjà crées. Cette distinction contribue aux vérifications sémantiques et permet de détecter des erreurs. Par ailleurs il permet l’inférence de type (let a=42)… évitant de devoir préciser le type si celui inféré est adéquat.
4  0 
floyer
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 27/08/2024 à 10:25
La syntaxe de Rust ne me semble pas parfaite non plus (je pense qu’il faut un peu d’habitude). Notamment pour les chaînes de caractères (où il y a pas mal de & à placer ici où là).

Mais critiquer la syntaxe avec let et les tuples alors que c’est assez naturel:

let tuple = ('Hello', 5, 3.14);

Je pense que l’exemple est fort mal choisi.

Bon évidemment tuple.0 surprendra le programmeur Python (habitué à tuple[0]). Mais pas de quoi disqualifier le language.
3  0 
Pyramidev
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 27/08/2024 à 19:47
Citation Envoyé par 23JFK  Voir le message
Pour le let, c'est surtout qu'il faille saisir 3 lettres à chaque fois... il ne semble pas y avoir d'opérateur séquentiel comme en C : pour être clair sa donne des trucs du genre ("en C" int a, b, c, d ; "en Rust" let a : u64 let b : u64 let c : u64 let d : u64 ) Désolé, mais à la fin, c'est le C qui gagne.

En Rust, on peut écrire :

Code Rust : Sélectionner tout 
1
2
3
4
5
6
7
8
9
10
fn main() { 
    let (a, b, c, d); 
    a = 1; 
    b = 2; 
    c = 3; 
    d = 4; 
    for (id, value) in [("a", a), ("b", b), ("c", c), ("d", d)] { 
        println!("{id} == {value}"); 
    } 
}
On peut aussi écrire :

Code Rust : Sélectionner tout 
1
2
3
4
5
6
fn main() { 
    let (a, b, c, d) = (1, 2, 3, 4); 
    for (id, value) in [("a", a), ("b", b), ("c", c), ("d", d)] { 
        println!("{id} == {value}"); 
    } 
}
3  0 
Christophe
Avatar de Christophe
Responsable Systèmes https://www.developpez.com
Le 30/08/2024 à 7:49
Il y a de gros projet sérieux en Python mais le prob n'est pas là, on parle du noyau là. Je ne pense pas que le Python soit adapté à ça.
3  0 
floyer
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 27/08/2024 à 17:47
Effectivement, si taper des lettres de plus t’est pénible, le C est peut-être préférable (peut-être lorgner sur APL réputé plus compact ?). Mais les constructions de plus haut niveau (pas de malloc à transtyper), free implicite, etc font que le language présente des avantages. J’avoue que j’aurais a priori plus confiance pour du code en Rust qu’en C. S’il compile, tu as déjà une partie des bugs potentiels détectés. Les autres aspects me semblent un peu secondaires.

(J’utilise actuellement plutôt OCaml qui est assez efficace, même si moins que C/Rust, mais présente le bon niveau d’abstraction).
2  0 
NotABread
Avatar de NotABread
Membre actif https://www.developpez.com
Le 27/08/2024 à 17:53
Je trouve la comparaison un poil injuste dans la mesure où le cas idéal de Rust est d'user de l'inférence de type alors qu'en C, on préféra expliciter le type.
Donc, en utilisant le typage automatique, Rust fait gagner une lettre (auto fait parti du standard 23 de C). Quite à pousser le vise sur le nombre de lettre, on peut compter le nombre de lettre des types de base:
- 'double' => 'f64'
- 'float' => 'f32'
- 'unsigned long long int' => 'u64'.
Bref, je trouve l'argument un peu léger, je ne pense pas qu'un code C en équivalent Rust soit significativement plus long pour le rayer des potentiels remplaçant de C.
Par contre mentalement, ça peut être agaçant de taper trois fois les même lettres partout dans le code.
2  0 
floyer
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 27/08/2024 à 18:46
Il me semble que les int du C sont propres à l’implémentation. Si je veux vraiment du 64 bits (pour des échanges avec le réseaux selon un protocole donné), j’utiliserai int64_t ou uint64_t comme équivalent des i64 ou u64 de Rust. (Cela reste plus long et il faut le include stdint.h).
1  0 
floyer
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 02/09/2024 à 0:00
Je pense que les questions de syntaxes diviseront toujours... entre ADA (LOOP ... END LOOP), C ( loop { ... } ) et Python (loop: <indented block>… ou encore la notation type var vs. var:type il y en aura toujours pour préférer une approche ou une autre.

NB: On trouve aussi 1:10 chez Python (dans les indices).

Je trouve la notation 0..10 assez simple mais peut-être piégieuse (utiliser 0..=10 pour aller vraiment à 10 comme dans un for i = 0 to 10 Pascal/OCaml).

Et itérer sur des tableaux Rust est tout de même plus simple que sur des vecteurs C++. (Pas de vec.begin(), vec.end()…)

Personnellement, j'ai fait du Pascal, C/C++, Perl, Python, Java, M/PowerQuery, maintenant de l'OCaml... Je trouve l'apport sémantique plus important que les éléments syntaxiques. Je pense qu'avec Rust, les éléments syntaxiques seraient appris bien plus vite que l'état d'esprit avec l'approche liée à l'appropriation (borrowing) des références, comment "contourner" ce genre de restrictions (quels smart-pointers utiliser, comment coder https://en.wikipedia.org/wiki/Dancing_Links), mais c'est vrai, qu'une approche à la Java/Javascript imitant C/C++ aurait pu être choisie pour ne pas trop «*dépayser*».
1  0 
Commenter Signaler un problème