IdentifiantMot de passe
Loading...
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 s'exprime à nouveau à propos du débat sur le choix entre C ou Rust pour le développement du noyau Linux
Et laisse entendre que le Rust peut aider à corriger des erreurs commises en C

Le , par Patrick Ruiz

39PARTAGES

24  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. La situation à date est telle que les mainteneurs habitués au langage C refusent de porter le code existant en Rust ou de passer du temps pour aider d’autres contributeurs à le porter en Rust. Linus Torvalds s’est à nouveau exprimé sur ce débat et il en ressort que le langage Rust peut aider à corriger des erreurs commises en langage C.

« Le C est, en fin de compte, un langage très simple. C'est l'une des raisons pour lesquelles j'apprécie le C et pour lesquelles beaucoup de programmeurs C apprécient le C, même si le revers de la médaille est évidemment que, parce qu'il est simple, il est aussi très facile de faire des erreurs », a-t-il déclaré.

En effet, Linus Torvalds est d’avis que le langage Rust est une solution d’avenir pour le développement du noyau. Il considère la prise en charge de Rust pour le développement du noyau Linux 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.


Mais Les habitués du langage C n’entendent pas se laisser embarquer dans ce qu’ils appellent la nouvelle religion du Rust

Les mainteneurs du noyau réfractaires à la mise à jour des bases de code du noyau Linux vers le langage Rust ont fait savoir quelle est leur position lors d’une présentation des systèmes de fichiers Linux et des besoins en termes de migration des bases de code vers le Rust. Il était question pour ces derniers de créer des passerelles permettant de faciliter l’atteinte de cet objectif. L'un des membres de l'auditoire a exprimé son désaccord en disant : « Vous essayez de convaincre tout le monde de passer à la religion du Rust, mais cela n’arrivera pas. »


Ces derniers multiplient donc des attitudes qui frustrent certains mainteneurs Rust qui choisissent de quitter le navire : « Ce type de traitement est exactement la raison pour laquelle j'ai entamé le projet @redox_os en partant de zéro et en l'écrivant principalement en Rust. Il y a beaucoup de résistance aux changements bénéfiques, même mineurs, dans Linux et les projets connexes. C’est la raison pour laquelle je n'essaie même plus de contribuer au noyau Linux. Il y a des projets pour lesquels vous devrez inévitablement faire passer vos changements devant des mégalomanes pédants et condescendants, et si le noyau Linux n'est pas seulement développé par ce type de personnalité, il est aussi contrôlé par lui de manière écrasante. »

Source : Linus Torvalds

Et vous ?

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

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

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

Avatar de NotABread
Membre habitué https://www.developpez.com
Le 20/09/2024 à 22:25
Ca dépend d'où tu mets ta barrière entre le haut niveau et le bas niveau. Dans la mesure où Rust t'impose de savoir ce qu'il se passe avec la mémoire et que cela est une forte contrainte dans l'écriture d'un programme, je dirai plutôt que Rust est bas niveau, à l'inverse de Python qui est très permissif sur l'écriture et masque la gestion de la mémoire.
Mais d'après certain, C serait un langage de haut niveau d'après la définition Wikipédia d'un langage de haut niveau
https://fr.wikipedia.org/wiki/Langag...de_haut_niveau
Un langage de haut niveau fait abstraction des caractéristiques techniques du matériel utilisé pour exécuter le programme, tels que les registres et les drapeaux du processeur
Aussi, Rust et C sont du même ordre de grandeur du point de vu performance. Pour certain problème, C est devant, pour d'autre c'est Rust. On peut dire qu'ils sont au même niveau en perf
https://benchmarksgame-team.pages.de.../rust-gcc.html

Le gros avantage du C reste sa simplicité, qui font qu'il est facile d'écrire un compilateur pour une plateforme personnalisé. Si on connait bien l'assembleur et le C, on sait à peu près ce que donnera l'assembleur d'un programme C
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 21/09/2024 à 13:44
Comme pour a peu prêt tout ce qu'on dit a propos de Rust, il y a une petite astérisque implicite qui dit indique "* sauf si on utilise du code unsafe".

En l’occurrence, ces fonctions ne sont normalement pas utilisées directement. Elles sont utilisées en interne par les types de base de la bibliothèque qui font des allocations sur le tas comme Vec, Box, Rc, ... A moins de vouloir remplacer ces types par des implémentations maison, on en a pas besoin.
3  0 
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 23/09/2024 à 11:16
Citation Envoyé par NotABread Voir le message
Le multithread est assez simple en Rust. Tu peux utiliser tokio pour te faciliter la vie, sinon tu as des thread que tu peux créer assez simplement, ou utiliser des coroutines (fonction marquée async).
J'ai l'impression que les coroutines restent privilégiée car la répartition de leur exécution sir les threads est faite efficacement de base.
Je ne comprends pourquoi utiliser tokio pour du multithread.
tokio te fournit un runtime pour faire de la programmation concurrente, et dans ce cadre de gérer plus de threads que n'autorise l'OS.
Mais la programmation multithread (non asynchrone) est directement accessible depuis la librairie standard.
Le fait d'être asynchrone complexifie sensiblement la programmation comparé au multithread. Et le multithread sans runtime est plus performant pour paralléliser des sections de calcul courtes:
https://stackoverflow.com/questions/...nchronous-code
Async/await does not give you any parallelism, only concurrency. That means that any sync operation using async/await to divide the work will just run one part after the other, not faster than without async/await and in fact slower because it adds overhead.

You can only get parallelism via threads, and you are limited to the number of cores you have in your system.

Some async runtimes do run the code in parallel, using multiple threads, so you will get some parallelism (and therefore speed) if you'll use them correctly; but this just adds overhead over using threads directly, or using a library such as rayon that avoids async/await and parallelizes the code using threads only.

If you're not I/O bound, don't use async/await. You have nothing to gain.
Par exemple, j'aurais plutôt tendance à utiliser rayon pour paralléliser un calcul sur une collection.
Citation Envoyé par NotABread Voir le message
Le plus dur, c'est de satisfaire le borrow checker qui demandera que le thread/la coroutine possède ce qu'il veut modifier ou que les potentiels data race soient protégés par des types sûrs (et attention, le compilo ne protège pas du dead lock ni des goulots d'étranglement).
Au passage, les scopes permettent de faire du multithread (sans runtime) avec des références (non mutables tout au moins). Pour faire la même chose avec tokio, ... il me semblait que pour l'instant, il fallait transmuter du lifetime.

Citation Envoyé par Uther Voir le message
Oui en Rust les références sont de simple pointeurs bas niveau. La différence et que le compilateur surveille la façon dont ils sont utilisés et leve une erreur si leur usage est susceptible de commettre une erreur mémoire.
Rust a aussi des pointeur simples, mais ils ne sont déréférençables que sans les blocs unsafe
Pour compléter cette réponse, une référence est un pointeur avec en plus de l'information abstraite apportée par le typage pour permettre au compilateur de contrôler l'usage de la mémoire.
En C on a un exemple d'information porté par le typage, avec le mot clef restrict. En terme d'optimisation à la compilation, il produit des résultats similaires aux références de Rust.

En revanche, les pointeurs/references Rust sont des fat pointers pour les slices et les trait objects.
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 21/09/2024 à 7:43
Citation Envoyé par NotABread Voir le message
Ca dépend d'où tu mets ta barrière entre le haut niveau et le bas niveau. Dans la mesure où Rust t'impose de savoir ce qu'il se passe avec la mémoire et que cela est une forte contrainte dans l'écriture d'un programme, je dirai plutôt que Rust est bas niveau, à l'inverse de Python qui est très permissif sur l'écriture et masque la gestion de la mémoire.
Mais d'après certain, C serait un langage de haut niveau d'après la définition Wikipédia d'un langage de haut niveau
La question de ce qu'est un langage de haut niveau reste en effet nébuleuse, il n'y a pas de définition officielle, je pense qu'il faut prendre l'habitude de préciser ce que l'on entend entre les différents types de classification:

  • Le dépendance au processeur :
    C'est en effet la première définition historique. Tous les langages d'assemblage sont de bas niveau. Il ne s'agit pas d'un seul langage, car parler d'assembleur est une généralisation, il y a en fait plusieurs langages différents, au moins un par architecture, et même sur la même architecture il peut y avoir des syntaxe différentes.
    Tout le reste est un langage de haut niveau, aussi bien C, C++, Python, JavaScript que Rust.


  • Le langage système:
    Un langage système permet de manipuler assez précisément des notions proches du matériel comme la mémoire via des pointeurs ou assimilé. Dans ce cas là C, C++ et Rust sont des langages système que Python et JavaScript ne le sont pas.


  • Le niveau d'abstraction:
    Certains langages peuvent fournir des moyen d'abstraire certaines chose sans que ça soit forcément impactant sur les performances. C offre les fonctions, les structures et les unions, mais ça reste très limité. Les vieux Basic (avant Visual Basic), même si il étaient dépendants d'un interpréteurs, étaient aussi dans ce cas là. On peut dire que ces langages ont un faible niveau d'abstraction
    D'autres langages offrent des concepts plus abstraits comme les classes(C++, JavaScript), traits(Rust), générique(C++,Rust), programmation logique(Prolog), par liste (Lisp). On peut dire que ces langages ont un haut niveau d'abstraction.


Citation Envoyé par NotABread Voir le message
Le gros avantage du C reste sa simplicité, qui font qu'il est facile d'écrire un compilateur pour une plateforme personnalisé. Si on connait bien l'assembleur et le C, on sait à peu près ce que donnera l'assembleur d'un programme C
Même ça, ça n'est plus tout a fait vrai, les compilateur C avancés modernes comme gcc ou clang sont des monstres d'optimisation qui peuvent surprendre.

Citation Envoyé par Zeeraptor Voir le message
La gestion de la mémoire en Rust je ne me souvient pas...quel mechanisme? Quelque chose de similaire avec les pointeurs?
Oui en Rust les références sont de simple pointeurs bas niveau. La différence et que le compilateur surveille la façon dont ils sont utilisés et leve une erreur si leur usage est susceptible de commettre une erreur mémoire.
Rust a aussi des pointeur simples, mais ils ne sont déréférençables que sans les blocs unsafe
2  0 
Avatar de floyer
Membre confirmé https://www.developpez.com
Le 02/10/2024 à 12:54
Citation Envoyé par OuftiBoy Voir le message
Voilà une partie très intéressante. Je reprend les chiffres donnés: 2288 en 20 ans. 2288/20 = 144,4. 15,9% de ces vulnérabilités à des problèmes lié au C (gestion mémoire, dépassement de tampons, allocation non libérées, accà des zones mémoire invalide ou libérée, etc)

15,9% de 144,4, c'est en arrondissant [B]30[/], soit 1,5 vulnéralité par an. Comparée à l'immense base de code du noyau linux, c'est particulièrement faible. Et ça n'implique certainement de changer le langage utilisé pour ce noyau.
1,5 par an cela fait peu… mais regarde :

https://www.cvedetails.com/product/4...l?vendor_id=33

645 vulnérabilité en 2024 (pas encore terminée) pour des corruptions de mémoire.

Même si cette année semble catastrophique, on est bien au delà des 1,5 par ans. (17 mini… 70 ou plus dans la plupart des années). On n’a pas les mêmes sources.

645 qui pourraient en grande partie être évité par une language plus sûr, cela fait réfléchir.
2  0 
Avatar de Minato Sensei
Membre régulier https://www.developpez.com
Le 02/10/2024 à 15:59
Citation Envoyé par Patrick Ruiz Voir le message
[B][SIZE=4]Les principaux mainteneurs du noyau Linux sont des quinquagénaires. Certains se rapprochent même de la soixantaine. Ce sont des âges pour lesquels on est considéré dans certains pays comme étant trop vieux pour exercer dans la filière du développement de logiciels. C’est donc sans surprise que la question du passage à la future génération de mainteneurs du noyau Linux revient constamment sur la table. Très évasif sur cet aspect, Linus Torvalds signe que « c’est une bonne chose que les vieux continuent à être à la manœuvre » tout en soulignant la difficulté le potentiel impact de cet état de choses sur l’intégration des jeunes mainteneurs.
Oui mais non. En quoi ce serait une bonne chose que les « vieux continuent à être à la manœuvre » ? Avec cette philosophie on n'aurait jamais ce gamin à la tête de l'Etat (encore moins cet ancien premier ministre, tient), on se contenterait d'un « vieux à la manœuvre ». À mon avis, il serait plus logique de susciter l'intérêt des jeunes mainteneurs pour le C. Après avec l'arrivée du C++, qui lui aussi voit désormais plusieurs recommandations en faveur d'autres langages comme le Rust, est-ce qu'intéresser les jeunes au C pourrait être une chose aisée / réalisable ? À voir
2  0 
Avatar de NotABread
Membre habitué https://www.developpez.com
Le 20/09/2024 à 22:36
Citation Envoyé par N_BaH Voir le message
ce n'est donc pas si clair.
Oui, c'est clair, sinon on aurait que l'assembleur en bas niveau de nos jour. De nos jour on parle plus de langage bas niveau quand il faut savoir manipuler la mémoire proprement et avec typage statique, et haut niveau quand on fait abstraction de la mémoire avec typage dynamique
1  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 23/09/2024 à 15:45
Citation Envoyé par Gugelhupf Voir le message
Oui il suffit de regarder les documentaires sur la création du langage C, ils le qualifient de haut niveau parce qu'ils le comparent avec l'assembleur qui est couramment utilisé à l'époque. Pour moi c'est très simple, la notion de haut niveau/bas niveau n'a rien à voir avec la complexité d'écriture ou de compréhension du code : Ton langage produit un binaire qui requiert une VM avec un système de garbage collector/ramasse-miettes ? Alors c'est un langage de haut-niveau, pour qu'un langage soit de bas niveau il doit être prédictible, on doit connaitre toutes les instructions CPU du programme à l'avance et donc sans interférence de garbage collector/ramasse-miettes
Le langage dont on connaît toutes les instruction, ça n'existe plus depuis au moins 30 ans, les optimiseurs moderne sont fabuleux, mais parfois sont surprenant.
Ce qu'on a de plus prédictible après l'assembleur, c'est ce qu'on appelle les langages système, dont on a une bonne idée de la façon dont est allouée la mémoire. Pas la peine d'utiliser le termes de haut et bas niveau, qui sont floue pour cela alors qu'on en a une plus précise (quoique pas parfaite non plus).
1  0 
Avatar de smarties
Expert confirmé https://www.developpez.com
Le 20/09/2024 à 15:29
Si ça se trouve, ça va se terminer dans plusieurs années avec Redox OS aura rattrapé son retard en ayant récupéré tous les développeurs Rust qui sont sur le noyau C (pour les raisons évidemment citées du créateur de RedoxOS)... Et les utilisateurs (particuliers et entreprises) migreront vers celui-ci car Rust offre la sécurité mémoire sans impacter les performances.
0  0 
Avatar de Zeeraptor
Membre à l'essai https://www.developpez.com
Le 20/09/2024 à 22:29
Rust est clairement impressionnant...

Le C restera un roc pour l'apprentissage et la légereté

Je n'ai jamais programmer en assembleur mais le HLA m’intéresse
0  0