Discussion :

[OuftiBoy]

Avant que les les défenseurs acharnés de Rust ne me tombe dessus, je précise que je n'ai rien contre ce dernier, qui pour ce que j'en ai vu, est très prometteur, même si je ne suis pas enthousiasmé personnellement par ce dernier (mais ce n'est pas le sujet).



Je comprend les anciens mainteneurs de longue date, qui ont accompli (en C) un travail de dingue sur le noyau.

Ils n'ont rien contre Rust, mais il faut comprendre et accepter qu'ils n'ont pas envie (à leur âge), de continuer.

Je pense que tout le monde est d'accord pour dire que la récriture complète du noyau linux en Rust, n'est pas une bonne idée. Techniquement, je peux comprendre que de nouveaux ajouts soit fait en [B]Rust[/R], mais cela pose certains problèmes:

• Deux langages différents dans une base de code, ça complexifie la chaîne de production.

• Y'a-t-il suffisamment de développeurs très compétents en Rust pour garantir l'évolution et la maintenance d'un projet de cette envergure ?

• Si la balance se fait vers Rust, qui voudra bien assurer la maintenance du vieux code C ?

• Si certains nouveaux contributaires veulent qu'on accepte d'introduire Rust dans la base de code, ils doivent aussi accepter de maintenir et permettre d'évoluer tout ce qui est et restera en C

Je ne suis pas spécialiste en Rust, mais j'ai lu (désolé, je n'ai pas noté les références) que bon nombres du code Rust de bas niveau se fait en mode unsafe, pour contourner la rigidité de Rust sur certaines parties de ce code. Et, dites-moi si je me trompe, Rust en mode unsafe, n'apporte pas grand chose au niveau sécurité par rapport au C. Je peux donc comprendre la réticences de bon nombres d'excellents développeurs C qui ne jugent pas nécessaires/souhaitable d'ajouter la complexité d'une base de code utilisant 2 langages.

Les "Pro Linux" (Perso, je ne suis ni Pro, ni Contre), n'ont eu de cesse de dire (à juste tire), que Linux était meilleur, plus stable, moins sujet aux vulnérabilités que d'autres OS. Et pourtant, tout cela a été fait en C...

BàV et Peace & Love

[imperio]

Je vais tenter de répondre point par point parce qu'il y a pas mal d'incompréhension.

Ils n'ont rien contre Rust, mais il faut comprendre et accepter qu'ils n'ont pas envie (à leur âge), de continuer.

Pourquoi ne pas partir à la retraite dans ce cas ? Pour l'avenir du projet, il vaut mieux permettre d'utiliser un langage plus récent (qui correspond aux besoins du projet) car il y aura plus de développeurs maitrisant ce langage. C'est l'argument principal de Linus pour pousser Rust dans le kernel (en plus des avantages fournis par Rust).

Je pense que tout le monde est d'accord pour dire que la récriture complète du noyau linux en Rust, n'est pas une bonne idée.

C'est un but long terme. Si une partie fonctionne, je ne pense pas qu'ils la réécriront avant un bon moment.

Techniquement, je peux comprendre que de nouveaux ajouts soit fait en [B]Rust[/R], mais cela pose certains problèmes:

• Deux langages différents dans une base de code, ça complexifie la chaîne de production.

• Y'a-t-il suffisamment de développeurs très compétents en Rust pour garantir l'évolution et la maintenance d'un projet de cette envergure ?

• Si la balance se fait vers Rust, qui voudra bien assurer la maintenance du vieux code C ?

• Si certains nouveaux contributaires veulent qu'on accepte d'introduire Rust dans la base de code, ils doivent aussi accepter de maintenir et permettre d'évoluer tout ce qui est et restera en C

Je pense que le ratio développeur Rust/développeur C va lentement bouger en faveur de Rust (normal, le C commence à se faire vieux maintenant...). Mais même au-delà de ça, il serait dommage de se priver des avantages fournis par un nouveau langage.

Je ne suis pas spécialiste en Rust, mais j'ai lu (désolé, je n'ai pas noté les références) que bon nombres du code Rust de bas niveau se fait en mode unsafe, pour contourner la rigidité de Rust sur certaines parties de ce code.

Non. C'est pour appeler du code C ou alors pour appeler des intrinsics que les blocks unsafe sont nécessaires. Et dans le kernel linux, c'est plutôt commun le C.

Et, dites-moi si je me trompe, Rust en mode unsafe, n'apporte pas grand chose au niveau sécurité par rapport au C. Je peux donc comprendre la réticences de bon nombres d'excellents développeurs C qui ne jugent pas nécessaires/souhaitable d'ajouter la complexité d'une base de code utilisant 2 langages.

Hé bien oui, tu te trompes, même assez lourdement. Le code unsafe n'enlève pas les vérifications de Rust, par-contre ça te permet d'appeler des fonctions unsafe (donc des fonctions C notamment) et de déréférencer un pointeur. Ce sont grosso-modo les seules différences. Je ne sais pas trop pourquoi les gens pensent que l'unsafe enlèvent magiquement tous les checks de Rust...

Les "Pro Linux" (Perso, je ne suis ni Pro, ni Contre), n'ont eu de cesse de dire (à juste tire), que Linux était meilleur, plus stable, moins sujet aux vulnérabilités que d'autres OS. Et pourtant, tout cela a été fait en C...

Mouais. Tu me vois moyennement convaincu là. Vu le nombre de failles de sécurité qui sont corrigés tous les ans, je pense qu'il serait plus intéressant de faire une comparaison avec le nombre d'installations de l'OS corrélé avec le nombre d'utilisateurs. C'est toujours très difficile de déterminer ce genre de choses.

[Uther]

Je comprend les anciens mainteneurs de longue date, qui ont accompli (en C) un travail de dingue sur le noyau.
Ils n'ont rien contre Rust, mais il faut comprendre et accepter qu'ils n'ont pas envie (à leur âge), de continuer.

Qu'ils n'aient pas envie d'apprendre le Rust, c'est très compréhensible. Mais s'opposer activement au travail des autres, c'est un autre problème. Il n'y a pas de mal dans un projet communautaire de demander l'assistance de quelqu'un qui connait la technologie plutôt que de rejeter tout au prétexte qu'on ne peut pas le faire soi-même.

Je pense que tout le monde est d'accord pour dire que la récriture complète du noyau linux en Rust, n'est pas une bonne idée. Techniquement, je peux comprendre que de nouveaux ajouts soit fait en [B]Rust[/R], mais cela pose certains problèmes

En effet la réécriture de tout Linux en Rust n'est pas un objectif pour le moment et si elle devait se faire ça sera certainement pas avant plusieurs dizaines d'années.
Il faut comprendre que la majorité du code de Linux est constitué des modules (des drivers) que l'on peut traiter de manière relativement indépendante. Ces modules peuvent maintenant être écrits en Rust, mais pour le moment le cœur du noyau reste en C et il n'y a aucun plan officiel pour que ça change. Ça pourrait peut-être arriver dans le futur mais pas avant très longtemps. Il faudrait déjà que les module en Rust deviennent largement majoritaires pour que l'on commence a l'envisager.

Deux langages différents dans une base de code, ça complexifie la chaîne de production.

En effet c'est le rôle du projet Rust4Linux de mettre en place la chaine coté Rust pour que ça marche au mieux possible, mais c'est difficile de nier que ça apporte forcément un minimum de complexité générale, au minimum ça impose l'ajout d'un compilateur Rust. Ceci dit au vu de la séparation en modules, la plupart les personnes qui font un driver en C n'ont pas a se soucier du Rust et vice versa.

Y'a-t-il suffisamment de développeurs très compétents en Rust pour garantir l'évolution et la maintenance d'un projet de cette envergure ?

C'est en effet la question, et c'est pour ça que le support de Rust est limité pour le moment aux modules. Le but est de permettre une transition progressive et voir comment les choses se passent sur la durée.

Si la balance se fait vers Rust, qui voudra bien assurer la maintenance du vieux code C ?

La situation serait la même que pour le Rust en ce moment mais inversée. Les modules C resteraient développés en C, tout comme les modules Rust sont actuellement développés en Rust. Si il n'y a plus personne pour assurer la maintenance d'un module en C, une migration pourrait être envisagée, au cas par cas.

Je ne suis pas spécialiste en Rust, mais j'ai lu (désolé, je n'ai pas noté les références) que bon nombres du code Rust de bas niveau se fait en mode unsafe, pour contourner la rigidité de Rust sur certaines parties de ce code. Et, dites-moi si je me trompe, Rust en mode unsafe, n'apporte pas grand chose au niveau sécurité par rapport au C. Je peux donc comprendre la réticences de bon nombres d'excellents développeurs C qui ne jugent pas nécessaires/souhaitable d'ajouter la complexité d'une base de code utilisant 2 langages.

C'est vrai qu'en bas niveau on peut avoir un besoin spécifique de recourir au unsafe, par exemple pour accéder directement aux adresses mémoires qui permettent de manipuler le matériel. Mais dans la pratique ça n’arrive que dans des parties très limitée du code que les blocs unsafe permettent d'identifier efficacement. Les premiers retours montrent que même sur des drivers, le recours au unsafe reste relativement rare. De loin le premier usage de unsafe que je constate en Rust, c'est juste pour s'interfacer avec un code C unsafe par nature.

Les "Pro Linux" (Perso, je ne suis ni Pro, ni Contre), n'ont eu de cesse de dire (à juste tire), que Linux était meilleur, plus stable, moins sujet aux vulnérabilités que d'autres OS. Et pourtant, tout cela a été fait en C...

La comparaison se faisant avec d'autres OS aussi écrits en C, ça ne ne dit rien sur la sécurité du langage en lui même.
Linux, comme ses concurrents, a cependant eu de nombreuses vulnérabilités liées à la sécurité mémoire.

[Uther]

Pourquoi ne pas partir à la retraite dans ce cas ? Pour l'avenir du projet, il vaut mieux permettre d'utiliser un langage plus récent (qui correspond aux besoins du projet) car il y aura plus de développeurs maitrisant ce langage. C'est l'argument principal de Linus pour pousser Rust dans le kernel (en plus des avantages fournis par Rust).

Pour le coup, pousser des gens très compétents à la retraite s'il ne le souhaitent pas me parait un problème. Si c'est comme ça qu'on présente sérieusement l'introduction de Rust, il ne faut pas s'étonner que les gens le traitent comme une menace plutôt qu'une opportunité.
Il reste clairement assez de C a écrire pour des dizaines d'années, les experts barbus ne sont pas encore tous bon pour l'ANPE Pole Emploi France travail.

C'est un but long terme. Si une partie fonctionne, je ne pense pas qu'ils la réécriront avant un bon moment.

Ce n'est clairement pas un but annoncé en tout cas. Rien n’empêche que ça le devienne à l'avenir, mais le seul objectif pour le moment est de permettre de faire des modules en Rust qui s’intègrent dans la base existante.

Non. C'est pour appeler du code C ou alors pour appeler des intrinsics que les blocks unsafe sont nécessaires. Et dans le kernel linux, c'est plutôt commun le C.

Dans les drivers et les OS, il y a quand même des usages particuliers du unsafe, par exemple pour permettre d'écrire à des endroits fixes de la mémoire, ou faire de l'assembleur pour accéder a des fonctionnalités particulières des processeurs, ...

Hé bien oui, tu te trompes, même assez lourdement. Le code unsafe n'enlève pas les vérifications de Rust, par-contre ça te permet d'appeler des fonctions unsafe (donc des fonctions C notamment) et de déréférencer un pointeur. Ce sont grosso-modo les seules différences. Je ne sais pas trop pourquoi les gens pensent que l'unsafe enlèvent magiquement tous les checks de Rust...

En même temps certaines fonction unsafe comme "transmute" pouvant casser à peu prêt toute la sécurité offerte par le typage, je comprend comment on peut en venir a cette conclusion. Ce qu'il faut retenir c'est surtout que les blocs unsafe restent rares et permettent d'identifier simplement le code à risque et donc de réduire son usage au minimum.

[23JFK]

...

En plus la compilation n'est pas simplifiée puisqu'il faut à présent compiler deux codes sources différents pour avoir un kernel fonctionnel... Les amateurs LFS vont adorer.

[OuftiBoy]

Je vais tenter de répondre point par point parce qu'il y a pas mal d'incompréhension.

Merci

Pourquoi ne pas partir à la retraite dans ce cas ? Pour l'avenir du projet, il vaut mieux permettre d'utiliser un langage plus récent (qui correspond aux besoins du projet) car il y aura plus de développeurs maitrisant ce langage. C'est l'argument principal de Linus pour pousser Rust dans le kernel (en plus des avantages fournis par Rust).

C'est bien ce qu'il se passe, les anciens développeurs/mainteneurs arrivent tout doucement a se faire vieux, et se retirent petit à petit. Il faudra donc bien que les développeurs qui reprennent le flambeau, puissent également maintenir une grande partie de code écrit en C. Parce que même si Rust semble devenir plus populaire, il n'est pas certains que pour le développement de bas niveau (sur des petits microcontrolleurs) il puisse s'imposer ni même perdurer (pour certains µControlleurs, seul un compilateur C est disponible).

Ada fait aussi bien que Rust, et il existe depuis des décénnies, et pourtant il n'est pas forcément très utilisé.

C'est un but long terme. Si une partie fonctionne, je ne pense pas qu'ils la réécriront avant un bon moment.

Je suis totalement d'accord. Je pense même qu'ils ne devraient même pas essayer de réécrire quoique ce soit. Si je prend l'exemple du domaine bancaire, des tentatives on été faites pour réécrire le (très) vieux code COBOL, et ça n'a jamais abouti. Et la base de code est finalement restée en COBOL.

Je pense que le ratio développeur Rust/développeur C va lentement bouger en faveur de Rust (normal, le C commence à se faire vieux maintenant...). Mais même au-delà de ça, il serait dommage de se priver des avantages fournis par un nouveau langage.

Ce n'est que mon avis, mais le C est partout, dans pratiquement tous les domaines, il faut utiliser du C, et avant qu'il ne soit remplacé majoritairement par Rust, il va vivre encore des décénies. Je parierais bien, mais je serais 6 pieds sous terre depuis bien longtemps si/quand ça arrivera, et je ne pourrais pas payer mon paris...

Mais sinon, oui, si Rust a des avantages, il faut en profiter. Mais entre un "vieux développeur C" et un "Junior développeur Rust, mon coeur balance

Non. C'est pour appeler du code C ou alors pour appeler des intrinsics que les blocks unsafe sont nécessaires. Et dans le kernel linux, c'est plutôt commun le C.

Le mot "unsafe" est alors très mal choisi si là c'est son utilsation première (utiliser du code C unsafe). Il aurait fallu le nommer "c-compatible". C'est un peu d'humour... Quoique rien que le fait qu'il existe (le mode "unsafe") ça me fait penser au "friends" dans le C++. Ce n'est pas au même niveau, je suis bien d'accord. Mais de grand espoirs avaient été espéré avec le C++, et la POO. Avec le recul, on peut dire que ce n'est pas la panacée, malheureusement.

Hé bien oui, tu te trompes, même assez lourdement. Le code unsafe n'enlève pas les vérifications de Rust, par-contre ça te permet d'appeler des fonctions unsafe (donc des fonctions C notamment) et de déréférencer un pointeur. Ce sont grosso-modo les seules différences. Je ne sais pas trop pourquoi les gens pensent que l'unsafe enlèvent magiquement tous les checks de Rust...

Il ne les enlève pas tous, mais c'est justement là où ça fait mal qu'il est utilisé ce mode "unsafe"

Mouais. Tu me vois moyennement convaincu là. Vu le nombre de failles de sécurité qui sont corrigés tous les ans, je pense qu'il serait plus intéressant de faire une comparaison avec le nombre d'installations de l'OS corrélé avec le nombre d'utilisateurs. C'est toujours très difficile de déterminer ce genre de choses.

Je me suis sûrement mal exprimé, je voulais juste dire qu'on a su faire un OS de qualité (linux) avec du C.

En tout cas, merci pour le partage

BàT et Peace & Love.

[OuftiBoy]

Pour le coup, pousser des gens très compétents à la retraite s'il ne le souhaitent pas ne me parait un problème. Et si c'est comme ça qu'on présente sérieusement l'introduction de Rust, il ne faut pas s'étonner que les gens le traitent comme une menace plutôt qu'une opportunité. Il reste clairement assez de C a écrire pour des dizaines d'années, les experts barbus ne pas encore bon pour l'ANPE Pole Emploi France travail.

Tout à fait d'accord

Ce n'est clairement pas un but annoncé en tout cas. Rien n’empêche que ça le devienne à l'avenir, mais le seul objectif pour le moment est de permettre de faire des modules en Rust qui s’intègrent dans la base existante.

Dans les drivers et les OS, il y a quand même des usages particuliers du unsafe, par exemple pour permettre d'écrire à des endroits fixes de la mémoire, ou faire de l'assembleur pour accéder a des fonctionnalités particulières des processeurs, ...

En même temps certaines fonction unsafe comme "transmute" pouvant casser à peu prêt toute la sécurité offerte par le typage, je comprend comment on peut en venir a cette conclusion. Ce qu'il faut retenir c'est surtout que les blocs unsafe permettent d'identifier simplement le code à risque et donc de réduire son usage au minimum.

Je suis aussi d'accord, mais le risque, c'est que si c'est possible, ce mode "unsafe" ne soit trop souvent utilisé. En fait ce sont tout un ensemble de ces
"petites choses" qui ne m'enthousiasme pas dans Rust. Encore une fois, je ne suis pas spécialiste de ce langage, mais si les créateurs de Rust ont ajouté ce genre de petit contournements, il doit bien y avoir une raison

Et si je me penche sur la "meilleur" utilisation de la mémoire, là je ne suis carrément pas convaincu. Les concepts "Borrow" et tout le reste me semble plus compliqué que de savoir faire un alloc/free. Sinon, et là c'est une affaire de goût, la "syntaxe" ne m'attire pas non plus.

BàV et Peace and Love.

[Deus Vult]

ce qui fait que le langage C soit moins securisant c'est les developpeurs pour la plupart des cas. bien que ça soit difficile, je pense qu'avoir de bonnes habitudes peuvent eliminer la moitié des problèmes liés à la securité. avec l'essort des langages "modernes", la nouvelle generation s'appuie sur des verités trouvées sans avoir à verifier par elle-même:
"la programmation orientée objet est mieux que la programmation procedurale."
"le langage C a beaucoup de problèmes de securité".
bien que ce soit en partie vrai, il faut souligner que la negligence humaine est la principale source de cette insecurité.
à mon simple avis, la nouvelle generation des codeurs devraient s'interesser à des aspects beaucoup plus profonds tels que l'architecture des ordinateurs, les algorithmes.
en ce qui concerne l'essor de rust, j'avoue que plus d'une fois j'ai été seduit. mais en moi reste encore la certitude qu'il a encore de longues années pour être veritablement un langage systeme dans la même categorie que le C.

[Uther]

Je suis aussi d'accord, mais le risque, c'est que si c'est possible, ce mode "unsafe" ne soit trop souvent utilisé. En fait ce sont tout un ensemble de ces
"petites choses" qui ne m'enthousiasme pas dans Rust. Encore une fois, je ne suis pas spécialiste de ce langage, mais si les créateurs de Rust ont ajouté ce genre de petit contournements, il doit bien y avoir une raison

En effet Rust est un langage pragmatique et s'il a ajouté la mécanique de bloc unsafe, c'est bien parce que c'est parfois nécessaire pour diverses raisons ( Interaction avec C, besoin d'accès direct mémoire, structure de données particulière, optimisation, ...). Par contre la raison d'être de ces blocs unsafe, c'est justement d'être utilisés le moins possible. Ainsi on peut identifier clairement les zones a risque auxquelles il faut porter une attention particulière, là ou en C et C++ c'est potentiellement tout le programme qui peut poser des problème de sécurité mémoire. Bien évidement si la moité du code était unsafe, la fonctionnalité n'aurait aucun sens, ce n'est heureusement jamais le cas, sauf dans le cas particulier des wrapper vers des bibliothèques écrites dans d'autres autre langages. La majorité des crates Rust ne contiennent pas du tout de unsafe.

Et si je me penche sur la "meilleur" utilisation de la mémoire, là je ne suis carrément pas convaincu. Les concepts "Borrow" et tout le reste me semble plus compliqué que de savoir faire un alloc/free. Sinon, et là c'est une affaire de goût, la "syntaxe" ne m'attire pas non plus.

Savoir faire un alloc/free, dès qu'on sort des cas triviaux, c'est bien plus compliqué qu'il n'y parait. Au final le ownership et borrowing c'est juste une intégration dans le compilateur des règles de bonne conduite à appliquer si on veut bien gérer les allocation en C et C++ .

[imperio]

ce qui fait que le langage C soit moins securisant c'est les developpeurs pour la plupart des cas. bien que ça soit difficile, je pense qu'avoir de bonnes habitudes peuvent eliminer la moitié des problèmes liés à la securité. avec l'essort des langages "modernes", la nouvelle generation s'appuie sur des verités trouvées sans avoir à verifier par elle-même:
"la programmation orientée objet est mieux que la programmation procedurale."
"le langage C a beaucoup de problèmes de securité".
bien que ce soit en partie vrai, il faut souligner que la negligence humaine est la principale source de cette insecurité.
à mon simple avis, la nouvelle generation des codeurs devraient s'interesser à des aspects beaucoup plus profonds tels que l'architecture des ordinateurs, les algorithmes.
en ce qui concerne l'essor de rust, j'avoue que plus d'une fois j'ai été seduit. mais en moi reste encore la certitude qu'il a encore de longues années pour être veritablement un langage systeme dans la même categorie que le C.

Ce sont les arguments anti-Rust habituels en somme. Je sais pas si t'as jeté un oeil aux failles de sécurité ou autres de ces 10 dernières années, mais la proportion de ces failles étant dues à de la mauvaise gestion mémoire représente une grosse part. Et ce ne sont pas dans des petits produits. Littéralement tous les projets écrits en C/C++ ont ce problème, quelque soit le niveau des développeurs ayant travaillé ou travaillant dessus. Donc oui, c'est toujours un problème humain. Et c'est justement ce problème que des langages comme Rust (qui n'a pas créé le concept de propriété dans un langage de programmation, loin de là) espèrent résoudre ou au moins limiter autant que possible.

Un bon exemple c'est Android : tous les nouveaux développement se font en Rust dorénavant et l'impact sur les failles de sécurité est très intéressant (un article en parlant : https://security.googleblog.com/2022...ndroid-13.html).

[der§en]

J’ai pas vu ce que recouvrait pour lui des"absurdités non techniques" !

[Mingolito]

J’ai pas vu ce que recouvrait pour lui des"absurdités non techniques" !

Il n'a sans doute pas voulu détailler pour partir sans se mettre tous le monde à dos.
C'est comme dans une entreprise, tu peux aimer les 2 heures de programmation utile que tu fais tous les jours et tu sais que tu va souffrir 5 heures par jours à gérer des conneries plus ou moins inutiles voir chiantes, comme par exemple les réunions qui servent à rien, le reporting que personne le lit, la pression de ton chef et les bourdes de tes collègues.

[Uther]

Il a quand même donné pour exemple une vidéo prise lors d'une conférence entre experts du noyau Linux, où il se faisait attaquer vivement par des gens qui ne connaissaient visiblement pas Rust et n'avaient clairement pas envie de le connaitre.

[chrtophe]

ça sort du sujet noyau, mais comment ça se passe pour la libc avec Rust, il y a une libRust ?

[Uther]

Il y a bien sur un système de lib standard comme dans tous les langages, la particularité de Rust est qu'il y en a deux :

• "core" contient juste le minimum pour que le langage fonctionne (type et traits de base).
• "std" reprend "core et ajoute les fonctionnalités qui dépendent de l'OS (fichier, réseau, allocation mémoire, thread, processus, ...), et quelques types plus avancée (collection, chemins, ...). On reste loin de l'exhaustivité des bibliothèques Java ou Python.

Quand on développe un programme dans des environnements ou l'on a pas accès normal à l'OS (création d'OS, un driver, l'embarqué sans OS), on utilise le mode "nostd" où l'on à plus accès qu'à core. C'est l'équivalent du mode freestanding en C. Le cas du développement de drivers Linux en Rust est un exemple typique de code où l'on utilise le mode nostd.

Ceci dit la grande majorité des programmes Rust finaux utilisent la bibliothèque "std" classique qui donne accès aux fonctionnalités générales de l'OS, en utilisant parfois la libc en interne, vu que c'est le seul moyen stable qu'offrent la plupart des OS pour ce faire.

[chrtophe]

ok, donc on retrouve les fonctions classiques de la libc par le biais de std, qui utilise libc en interne donc avec les potentielles failles liées à la libc qui ne bénéicie pas des améliorations de sécurité de Rust.

[Astraya]

Il y a bien sur un système de lib standard comme dans tous les langages, la particularité de Rust est qu'il y en a deux :

• "core" contient juste le minimum pour que le langage fonctionne (type et traits de base).
• "std" reprend "core et ajoute les fonctionnalités qui dépendent de l'OS (fichier, réseau, allocation mémoire, thread, processus, ...), et quelques types plus avancée (collection, chemins, ...). On reste loin de l'exhaustivité des bibliothèques Java ou Python.

Quand on développe un programme dans des environnements ou l'on a pas accès normal à l'OS (création d'OS, un driver, l'embarqué sans OS), on utilise le mode "nostd" où l'on à plus accès qu'à core. C'est l'équivalent du mode freestanding en C. Le cas du développement de drivers Linux en Rust est un exemple typique de code où l'on utilise le mode nostd.

Ceci dit la grande majorité des programmes Rust finaux utilisent la bibliothèque "std" classique qui donne accès aux fonctionnalités générales de l'OS, en utilisant souvent la libc en interne, vu que c'est le seul moyen stable qu'offrent la plupart des OS pour ce faire.

Pour être précis, le core n'utilise pas de heap, I/O et tout ce qui en découlent. C'est vraiment le strict minimum du langage, c'est tout ce que le langage est ( tableau statique, référence, liftetime) c'est vraiment pour le pur embarquée, c'est comme du C sur des systèmes sans heap.

`std` est dépendant du système sur lequel il tourne ( il y a donc une implémentation spécifique au système pour `std` comme #ifdef _WIN32). Et donc std peut fournir tout ce que 'core' ne fournit pas.

Un 3ème crate est le crate `alloc`, qui fournit un moyen de gérer les allocations dynamiques. Le crate `std` utilise le crate `alloc` qui gère l'allocation dynamique avec le système sur lequel `std` tourne aka std::alloc) en fournissant une allocateur globale.

Toutes les librairies que j'ai faite en Rust sont ![no_std] même si je ne faut pas d'embarquer, car souvent je n'est juste pas besoin de heap ( hashage principalement) ou demandant de fournir un alloc.

[Astraya]

ok, donc on retrouve les fonctions classiques de la libc par le biais de std, qui utilise libc en interne donc avec les potentielles failles liées à la libc qui ne bénéicie pas des améliorations de sécurité de Rust.

Non, unsafe garde le check du borrow checker et autres vérifications.
Ce que unsafe autorise est simplement:

* Dereference a raw pointer
* Call an unsafe function or method
* Access or modify a mutable static variable
* Implement an unsafe trait
* Access fields of a union

Pour tout le reste Rust unsafe reste beaucoup plus safe que C.

De plus, unsafe permet de limiter la surface de code qui peut avoir un problème de gestion mémoire, on sait où est le code dangereux, en C le code dangereux est PARTOUT!

[Uther]

ok, donc on retrouve les fonctions classiques de la libc par le biais de std, qui utilise libc en interne donc avec les potentielles failles liées à la libc qui ne bénéficie pas des améliorations de sécurité de Rust.

Dans le cas du développement de drivers Linux en Rust, on est en mode nostd. Donc, non, on ne dépend pas de la libc.
Pour ce qui est de la bibliothèque std, elle est écrite en Rust et utilise ses propres routines autant que possible. Si elle utilise la libc, ce n'est généralement que pour ce qui implique des appels au noyau, vu que la plupart des OS (à part Linux) ne fournissent pas une API au noyau stable.

Non, unsafe garde le check du borrow checker et autres vérifications.
Ce que unsafe autorise est simplement:

* Dereference a raw pointer
* Call an unsafe function or method
* Access or modify a mutable static variable
* Implement an unsafe trait
* Access fields of a union

J'ai un petit problème avec cette présentation des choses. Certes un bloc unsafe ne débloque que les 5 actions que tu cites, mais ces actions ont possiblement des conséquences sur le borrow checker. C'est notamment le cas des les deux premières car, déréférencer un pointeur brut permet des accès mémoire que le borrow checker interdirait, et la fonction unsafe "transmute()" est capable de violer la sécurité des types et donc de tromper le borrow checker qui s'appuie dessus.
Donc oui le borrow checker n'est pas directement désactivé à l'intérieur du bloc unsafe, mais le bloc unsafe donne accès à des outils qui peuvent le mettre en défaut s'ils sont mal utilisés.

Pour tout le reste Rust unsafe reste beaucoup plus safe que C.

Là encore je ne suis pas entièrement d'accord car en Rust unsafe, pour éviter les comportement indéterminés, il y a des règles à ne pas enfreindre supplémentaires par rapport au C. Par exemple il faut s'assurer qu'une variable mutable ne peut être partagée, alors que ça ne pose pas directement de problème en C. Donc sur du code assez avancé, faire du code unsafe en Rust peut être plus compliqué que du C classique. Heureusement l'usage du unsafe, reste normalement très ponctuel.

De plus, unsafe permet de limiter la surface de code qui peut avoir un problème de gestion mémoire, on sait où est le code dangereux, en C le code dangereux est PARTOUT!

Sur ce point par contre je suis 100% d'accord. Tout l’intérêt des bloc unsafe c'est qu'ils rendent très facile à identifier les section de code a risque pour les réduire au minimum et, si ce n'est pas possible de s'en passer, de les auditer avec un attention particulière. Dans la pratique on se rend compte que le besoin de recourir à du code unsafe est très rare en dehors de l'interaction avec d'autre langages.
Même si on a pas un code que le compilateur peut garantir sûr à 100%, c'est un énorme progrès que de réduire considérablement la quantité de code à risque.

[floyer]

Pourquoi ne pas partir à la retraite dans ce cas ?

Il y a du vrai… pour pouvoir travailler sur les mêmes technologies de la sortie d’école à la retraite, il y a mieux que l’informatique. (Et même avec le même langage, les bibliothèques évoluent : hier Xaw/Xt/X, aujourd’hui Gtk).

L’avantage du C est qu’il est connu de plus de monde que le langage Rust… mais vu les avantages de Rust cela peut valoir le coup de changer, même si cela prendra du temps.