Discussion :

[floyer]

En gros,des tableaux sécurisés avec une notion système?

Qu’appelle tu une notion système ?

En tout cas, il y a une vérification des bornes du tableau. Soit à la compilation lorsque c’est possible, soit à l’exécution.

Par ailleurs pour des tableaux de taille variable, la taille du tableau est passé en paramètres implicite (si passé en référence).

Cela permet d’écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
fn affiche(t : &[int32])
{
  for a in t.iter() {
    println("{}",a);
  }
}

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.

Oui, en Rust on sait assez bien comment c’est stocké en mémoire et le choix stockage sur pile, vs sur le tas est explicite. Mais il n’y a pas de malloc, memcpy… où l’on doit indiquer une taille en octets. Par exemple.

La gestion de la mémoire impose des contraintes mais garantit l’absence de déréférencement invalide. Et si on ne respecte pas les contraintes, le compilateur le dit voire propose des corrections ! Avec le C il faut s’imposer des contraintes sous peine d’avoir un programme buggué. Le compilateur laissant passer beaucoup plus de choses.

Rust est globalement de plus haut niveau, sans vraiment sacrifier les performances.

[NotABread]

Oui, en Rust on sait assez bien comment c’est stocké en mémoire et le choix stockage sur pile, vs sur le tas est explicite. Mais il n’y a pas de malloc, memcpy… où l’on doit indiquer une taille en octets. Par exemple.

La gestion de la mémoire impose des contraintes mais garantit l’absence de déréférencement invalide. Et si on ne respecte pas les contraintes, le compilateur le dit voire propose des corrections ! Avec le C il faut s’imposer des contraintes sous peine d’avoir un programme buggué. Le compilateur laissant passer beaucoup plus de choses.

Rust est globalement de plus haut niveau, sans vraiment sacrifier les performances.

Ça n'est pas tout à fait exact, il y a bien des fonction pour la gestion manuelle de la mémoire, elles sont en unsafe. Cela ne fait pas parti du code idéal Rust et je ne sais pas dans quelles circonstance on se retrouve forcé à les utiliser (surtout que pour l’interopérabilité avec le C, on utilise libc)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
use std::alloc::{alloc, dealloc, Layout};
 
fn main() {
    unsafe {
        let layout = Layout::new::<u16>();
        let ptr = alloc(layout);
 
        *(ptr as *mut u16) = 42;
        assert_eq!(*(ptr as *mut u16), 42);
 
        dealloc(ptr, layout);
    }
}

[Uther]

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.

[fdecode]

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.

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.

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.

[Gugelhupf]

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

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

[Uther]

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

[Patrick Ruiz]

Linus Torvalds explique pourquoi la longévité des développeurs Linux est une bonne chose : « C’est un bon signe »
Lance-t-il sans répondre à la question du passage à la future génération de mainteneurs

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.

« Il peut sembler difficile d’intégrer l’équipe de mainteneurs en tant que jeune qui voit tous ces séniors encore aux commandes », reconnaît-il. C’est en toile de fond le débat sur le choix entre le langace C et le Rust pour le futur du développement du noyau qui prend un coup de neuf. En effet, les principaux mainteneurs du noyau Linux sont des habitués du langage C dont l’âge commence par le chiffre 5. Certains se rapprochent même de la soixantaine. La nouvelle génération de mainteneurs du noyau Linux semble plutôt constituée d’utilisateurs du langage Rust dont certains se plaignent déjà du traitement que leur infligent les habitués du langage C.

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

Les rapports font en effet état de ce qu’un sous-ensemble de contributeurs au noyau en langage C sont déterminés à rendre la vie dure aux mainteneurs Rust. Motif : Ils considèrent que Rust n’apporte pas de plus-value significative et préfèrent donc que ce langage de programmation soit mis de côté dans le cadre du développement du kernel.

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

Linus Torvalds lui-même est pourtant 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.

Source : Linus Torvalds

Et vous ?

Quel impact le comportement des habitués du langage C est-il susceptible d’avoir sur le futur du développement du noyau Linux ?

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

[vVDB.fr]

On assiste à une rupture du même ordre de linux quand Linus c'est lancé...
Donc aujourd'hui, Linus doit suffisamment segmenter linux pour que les pans définis puissent s'écrire et fonctionner en Rust et en C et que le meilleur gagne... Il doit y avoir émulation.
Les gens ont participé à linux avec cet esprit de compétition, de faire mieux qu'un Unix propriétaire...

[floyer]

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.

[Minato Sensei]

[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