Discussion :

[d_d_v]

Quelqu'un peut m'expliquer pourquoi c++ évolue, mais pas C ? En C++, n'en déplaise à Russinovich, quand j'alloue de la mémoire, j'utilise, en fonction de mes besoins, un vector, une map, un array, voire un new [] encapsulé dans un unique_ptr. Donc, pas de problème de mémoire si on est un minimum compétent. Pourquoi l'équivalent de string et des conteneurs de la STL ainsi que des pointeurs intelligents n'a jamais été ajouté au C, en utilisant des "pseudo-objets" puisque C n'est pas objet ?
Et puis, plutôt que d'utiliser encore un nouveau langage qui va finir comme toujours à proposer un mode unsafe que tout le monde aura tendance à utiliser, pourquoi ne pas inventer des extensions aux langages existants pour expliciter l'utilisation obligatoire d'un code securisé. Par exemple, en c++, du code encapsulé par une sorte de namespace spécial "safe { code sécurisé ... }". Si dans ce code, des new ou malloc explicites sont utilisés hors code de la STL et appels à des librairies externes, alors la compil finirait en erreur.

[Pyramidev]

pourquoi ne pas inventer des extensions aux langages existants pour expliciter l'utilisation obligatoire d'un code securisé

Dans le cas du C++, c'est techniquement possible, mais le comité C++ a refusé.
Le 11 septembre 2024, Sean Baxter avait proposé Safe C++.
Le 15 octobre 2024, pour contrer Sean Baxter, Herb Sutter a proposé d'ajouter des principes qui empêchent C++ d'avoir un sous-ensemble à la fois performant et sécurisé : P3466R0 "(Re)affirm design principles for future C++ evolution".
Le 24 octobre 2024, Sean Baxter a argumenté contre ces nouveaux principes ainsi que contre la proposition des "Safety Profiles" de Bjarne Stroustrup : Why Safety Profiles Failed.
En novembre 2024, le comité C++ a voté pour ces nouveaux principes à 29 voix pour, 22 neutres et 2 contre : Trip report: November 2024 ISO C++ standards meeting (Wrocław, Poland).
Le destin du C++ a été scellé.

[RenarddeFeu]

Ces guéguerres semblent assez puériles vu de l'extérieur.

[floyer]

Le C++ moderne intègre des avancées de Rust… donc on peut penser que l’avantage de Rust est moindre.

[Uther]

Tu penses a quoi précisément? Pour le moment le C++ n'a pas intégré grand chose qui vienne de Rust, c'est plutôt l'inverse.

Il y a plusieurs projets qui visent à reprendre des choses du Rust (SafeCpp, Carbon, FrontCpp, ...), mais rien qui ne semble concerner le C++ officiel pour le moment. Les profiles sont ce qui s'en rapproche le plus mais ça reste très nébuleux et ça n'arrivera pas avant dans quelques années.

[floyer]

@Uther : la formulation était maladroite : c’est plutôt Rust qui a copié C++ que l’inverse (STL, RAII…).

Je veux dire que par rapport à C, C++ intègre plusieurs avancées que l’on retrouve aussi dans Rust. Ainsi, si Linux avait été porté en C++, l’intérêt de Rust aurait été moindre.

[fdecode]

un mode unsafe que tout le monde aura tendance à utiliser,

Et qui ferait ça? un débutant en programmation Rust?

En Rust, on évite de programmer en unsafe, quand on est un programmeur confirmé. D'une part, parce qu'on maitrise le paradigme de programmation safe par défaut, d'autre part parce qu'on a appris à minimiser l'usage d'unsafe.
Et quand on est un débutant, la programmation unsafe a quelque chose de... suicidaire...

Ce n'est pas par idéologie, c'est un peu par philosophie, mais c'est surtout parce qu'un mode unsafe mal maitrisé est dangereux.
Un exemple bien connu est que le compilateur Rust peut faire des optimisations du code à partir de la sémantique de prêt ('&', '&mut' ...).
La sémantique de prêt est très contraignante pour les débutants. C'est l'une des premières choses qu'un débutant voudra contourner. Mais si on contourne cette sémantique par un unsafe (l'unsafe le permet, mais cette transgression est un UB), il y a le risque que le code compilé soit imprédictible. Dans l'exemple ci-dessous [playground] de contournement de la sémantique de prêt (on utilise une référence mutable pour créer simultanément une référence mutable et une référence non mutable), on obtient un résultat différent en mode Debug ou en mode Release:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
fn dup_ref_mut<T>(rx: &mut T) -> (& mut T, &T) {
    let px = rx as *mut T;
    unsafe { (px.as_mut().unwrap(),px.as_ref().unwrap()) }
}
 
#[no_mangle] 
fn adds(a: &mut i32, b: &i32) { *a += *b; *a += *b; }
 
fn main() {
    let mut a = 1; 
    let (ra, rb) = dup_ref_mut(&mut a);
    adds(ra, rb);
    println!("a = {}",a);
}

Donc, pour programmer unsafe, il faut au préalable s'assurer qu'on n'est pas dans un cas d'usage UB: c'est une connaissance de programmeur Rust confirmé.


Il me semble qu'il existe des outils pour tracer l'utilisation des unsafe. Donc, l'usage d'unsafe peut être régulé et être contrôlé par celui qui valide le code. Par exemple, des règles d'utilisation de l'unsafe sont édictées pour Redox, afin d'en limiter l'usage:
https://doc.redox-os.org/book/develo...safe-rust-code

[floyer]

Je suppose que tout les langages avec un mode unsafe (C#, Rust) proposent ce mode pour des bibliothèques bien supportées à des fins d’optimisation et pour des FFI (foreign function interface) où par principe les protection du language peuvent être incompatibles.

Pour tout programme normal, pas de unsafe, ou si vraiment, encapsulé dans des bibliothèques assez surveillées pour être sûre.

Et oui, l’idée n’est pas d’ouvrir une porte au débutant qui ne sait pas résoudre un problème lié aux règles d’emprunt.

[Uther]

Je veux dire que par rapport à C, C++ intègre plusieurs avancées que l’on retrouve aussi dans Rust. Ainsi, si Linux avait été porté en C++, l’intérêt de Rust aurait été moindre.

Je pense pas que ça aurait vraiment changé grand chose. A part RAII, qui il est vrai est a la base de Rust, la plupart des nouveautés de C++, ont surtout visé à améliorer l'ergonomie, mais pas vraiment la sécurité mémoire. La STL en particulier n'est absolument pas sécurisée.

C'est pour ça que c'est actuellement le bordel dans les différentes tentatives d'améliorer la sécurité. Il y a tout un historique de fonctionnalité problématiques qui font encore partie du cœur du C++ moderne. Si on veut faire quelque chose avec un niveau de garantie similaire à Rust, il faudrait changer beaucoup de choses dans les fondamentaux du langage.

[floyer]

Certes, un a = vecteur[i] n'est pas vérifié. Mais en C++ est ajouté la possibilité d'écrire :

Code :

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

for (int valeur : vecteur)  [...]

Ce qui évite des dépassements dès le codage. Je pense qu'il est préférable de proposer des idiomes qui incite à éviter lors du codage les dépassements que reposer sur la vérification run-time.

Mais il est vrai que STL ne vérifie pas toujours les bornes... cela y est presque (vecteur.at(i) vérifie mais pas vecteur[i] dommage).

Il aurait peut-être été préférable d'avoir un vecteur[i] qui vérifie et vecteur.unsafe_at(i) qui ne vérifie pas. De quoi préférer Boost ou Qt.

[fdecode]

et pour des FFI (foreign function interface) où par principe les protection du language peuvent être incompatibles.

Oui, c'est un des cas d'usage, où l'utilisation de unsafe n'est pas très risquée, même pour un débutant.

[Uther]

Je pense qu'il est préférable de proposer des idiomes qui incite à éviter lors du codage les dépassements que reposer sur la vérification run-time.

C'est justement la philosophie de Rust. La quasi intégralité de la sécurisation apportée par Rust se fait via des contrôles à la compilation. L'indexation directe est une des rares exceptions vu qu'il n'est pas possible de faire autrement. Ceci dit c'est un cas encore plus rare qu'en C++ vu que la seule syntaxe de boucle for disponible est l'équivalente au for "par range" en C++.

Mais il est vrai que STL ne vérifie pas toujours les bornes... cela y est presque (vecteur.at(i) vérifie mais pas vecteur[i] dommage).

C'est vrai que en C++ les méthodes les plus intuitives sont généralement les plus dangereuses, mais c'est loin d'être le seul problème de la STL. On peut, entre autre, avoir des pointeurs directement sur le contenu d'un vecteur qui vont devenir invalides s'il est redimensionné.

Oui, c'est un des cas d'usage, où l'utilisation de unsafe n'est pas très risquée, même pour un débutant.

Si la FFI ne transmet que des valeurs recopiées, en effet il n'y a pas de risque.
Par contre si elle transmet des pointeurs vers des données dont la durée de vie est gérée par le code C, au contraire c'est plutôt risqué. Ca va nécessiter une bonne connaissance de ce que fait le programme C avec sa mémoire et savoir réaliser l'abstraction correspondante en Rust safe. Si c'est mal fait ça peut introduire un problème mémoire.

[fdecode]

Si la FFI ne transmet que des valeurs recopiées, en effet il n'y a pas de risque.
Par contre si elle transmet des pointeurs vers des données dont la durée de vie est gérée par le code C, c'est plutôt risqué. Ca va nécessiter une bonne connaissance de ce que fait le programme C avec sa mémoire et savoir réaliser l'abstraction correspondante en Rust safe. Si c'est mal fait ça peut introduire un problème mémoire.

Oui, bien entendu.

[Mathis Lucas]

Linus Torvalds envisagerait de fusionner le code du noyau Rust en dépit des objections des mainteneurs
qui assimilent le mélange de Rust et du C à un « cancer » qui rendrait Linux impossible à maintenir

Deux camps continuent de s'opposer sur le sujet de l'intégration de Rust dans le noyau Linux : ceux qui voient Rust comme une opportunité d'améliorer la sécurité et la robustesse de Linux et ceux qui rejettent le mélange des langages C et Rust. Christoph Hellwig, l'un des mainteneurs du noyau, appartient au deuxième groupe et assimile ce mélange à un « cancer ». Toutefois, il a rapporté que le créateur de Linux, Linus Torvalds, est favorable à l'ajout de Rust dans le noyau et veut aller de l'avant dans ce projet. Selon Christoph Hellwig, Linus Torvalds aurait déclaré en privé qu'il passera outre le veto des mainteneurs pour fusionner le code du noyau Rust.

Linus Torvalds reste ouvert à l'idée d'intégrer le langage Rust dans le noyau Linux

Ces derniers mois ont été marqués par des discussions houleuses sur la question de l'ajout de Rust comme le deuxième langage de développement du noyau Linux. Le débat est devenu encore plus intense lorsque Christoph Hellwig a assimilé le mélange de Rust et de C dans le noyau Linux à un « cancer ». Christoph Hellwig, l'un des responsables du noyau, s'oppose catégoriquement à cette idée et affirme que « le mélange rendrait Linux impossible à maintenir ».

Il a déclaré : « si vous voulez rendre Linux impossible à maintenir à cause d'une base de code interlangage, faites-le dans votre pilote pour que vous ayez à le faire au lieu de répandre ce cancer dans les sous-systèmes centraux... Je ne veux pas qu'il s'approche d'une énorme base de code C que je dois maintenir ».

Mais Christoph Hellwig a récemment mentionné un échange privé avec Linus Torvalds qui montre que ce dernier veut tenter l'aventure Rust. Dans cet échange, Linus Torvalds aurait précisé qu'il passerait outre le veto des mainteneurs sur le code Rust au sein du noyau. Christoph Hellwig critique cette décision.

« Certains sous-systèmes peuvent décider de ne pas avoir de code Rust pour le moment, généralement pour des raisons de bande passante. C'est une bonne chose et on s'y attend ». Alors que Linus a dit en privé qu'il allait absolument fusionner du code Rust malgré l'objection d'un mainteneur. (Il l'a fait en privé au cas où vous chercheriez une référence.)

Ainsi, à partir de maintenant, en tant que développeur ou mainteneur Linux, vous devez faire face à Rust, que vous le vouliez ou non.

Le code Rust ne signifie pas seulement du code Rust [1] - les bindings ne ressemblent en rien à du code Rust idiomatique, ce sont des bêtes très différentes qui essaient de combler un énorme fossé sémantique. Et ils ne le font pas dans quelques endroits, parce qu'ils sont montrés dans chaque petit sous-système et bibliothèque en ce moment.

Ainsi, ces bindings se répandent partout comme un cancer et nous passons très rapidement d'un projet logiciel qui permet et s'efforce d'apporter des changements globaux qui améliorent le projet dans son ensemble à une compartimentation croissante [2]. Cela transforme Linux en un projet écrit dans plusieurs langages sans directives claires quant au langage à utiliser et à l'endroit où il doit être utilisé [3].

Même en dehors des bindings, une grande partie du code Rust ne sera pas très idiomatique en raison des structures de données du noyau qui sont intrusives et des structures de données autoréférencées comme les listes chaînées omniprésentes. Ne rendons-nous pas un mauvais service à la fois à ceux qui essaient d'amener la base de code existante dans un espace plus sûr et aux personnes qui font de la programmation système en Rust ?

Ayant travaillé sur des bases de code de ce type, elles sont mon pire cauchemar, parce qu'il y a une constante réécriture de parties du langage A au langage B pour une raison X, puis de nouveau pour une raison Z. Et cela sans l'habituel processus « créatif » de Linux qui consiste en des luttes intestines entre mainteneurs.

Les remarques de Christoph Hellwig contrastent avec les analyses du créateur de Linux, Linus Torvalds. Il est d'avis que Rust peut aider à corriger des erreurs commises en C. Il pense que Rust est une solution d’avenir pour le développement du noyau. Ainsi, Linus Torvalds 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 ».

Il a déclaré : « 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 ».

Les remarques de Christoph Hellwig sont jugées en violation du code de conduite

Hector Martin, chef de projet d'Asahi Linux, estime que « les remarques de Christoph Hellwig constituent une violation du code de conduite », mais doute que des mesures disciplinaires soient prises. Il estime que les développeurs de Rust for Linux devraient ignorer les préoccupations de Christoph Hellwig et soumettre leur correctif à l'approbation du patron du noyau, Linus Torvalds. Selon lui, l'avenir de Rust for Linux dépendra de la réponse de Linus Torvalds.

Et à en croire Christoph Hellwig, Linus Torvalds a bien l'intentien de fusionner le code du noyau Rust. Christoph Hellwig ajoute qu'il ne voit pas l'intérêt d'intégrer Rust. Selon lui, si l'objectif est de résoudre les problèmes liés à la sécurité de la mémoire, « d'autres pistes sont possibles et sont meilleures ».

J'aimerais comprendre quel est l'objectif de cette « expérience » Rust : si nous voulons résoudre les problèmes existants en matière de sécurité de la mémoire, nous devons le faire pour le code existant et trouver des moyens de l'adapter. Beaucoup de travail a été fait dans ce sens récemment et nous avons besoin de beaucoup plus.

Mais cela montre aussi à quel point les mainteneurs du noyau sont découragés par des choses triviales comme la vérification des débordements d'entiers ou la synchronisation imposée par le compilateur (comme dans l'assainisseur de threads de clang). Comment allons-nous combler le fossé entre une partie du noyau qui n'accepte même pas des règles relativement faciles pour améliorer la sécurité et une autre qui applique des règles encore plus strictes.

Si nous voulons simplement faciliter l'écriture de pilotes, un nouveau langage pour cela représente encore plus de travail et augmente la charge de travail des personnes déjà surchargées qui maintiennent l'infrastructure de base en forme. Je ne pense donc pas que ce document politique soit très utile. Pour l'instant, la règle est que Linus peut vous imposer ce qu'il veut (c'est son projet évidemment) et je pense qu'il doit l'énoncer clairement, y compris les attentes des contributeurs.

En ce qui me concerne, je peux m'occuper de Rust et je le fais très bien, j'adorerais amener le noyau dans un monde plus sûr pour la mémoire, mais m'occuper d'une base de code multilangage non contrôlée est un moyen assez sûr de me faire passer mon temps libre à autre chose. J'ai entendu quelques autres personnes marmonner quelque chose de similaire, mais tout le monde n'est pas aussi franc.

[1] J'ai écrit et travaillé sur une bonne partie du code Rust en espace utilisateur, mais je ne suis en aucun cas un expert, alors prenez ceci avec un grain de sel.

[2] L'idée de pilotes dans eBPF comme le fait HID n'est pas non plus très utile, même si j'aime eBPF pour certains cas d'utilisation.

[3] À moins que Linus ne l'impose à votre sous-système, ou que Dave ne décide que tout ce qui touche au matériel Nvidia doit être en Rust bien sûr.

Christoph Hellwig pourrait se retirer du projet Linux si Linus Torvalds fusionne le code du noyau Rust. Il reste donc à voir si Linus Torvalds acceptera directement le code du noyau Rust après un examen plus approfondi et une mise au point à l'avenir ou si Christoph Hellwig le fera passer lui-même après tout.

Le 7 février 2025, Hector Martin a demandé à être retiré de la liste des mainteneurs de Linux. « Je n'ai plus aucune confiance dans le processus de développement du noyau ou dans l'approche de la gestion de la communauté », a-t-il écrit dans une note adressée à la liste de diffusion du noyau Linux.

Pourquoi intégrer Rust dans le noyau Linux ?

La principale raison d'envisager l'utilisation de Rust réside dans ses caractéristiques de sécurité de la mémoire. Le noyau Linux est écrit en C, un langage qui, bien que puissant, nécessite une gestion minutieuse de la mémoire pour éviter les bogues. Le langage Rust facilite l'écriture de codes sûrs, réduisant potentiellement les vulnérabilités et améliorant la stabilité. La possibilité d'écrire des pilotes plus sûrs est donc une motivation clé pour l'adoption de Rust.

Il n'est pas prévu de réécrire l'ensemble du noyau Linux en Rust, mais de l'introduire progressivement, en commençant par les nouveaux pilotes de périphériques. Cette approche progressive vise à minimiser les perturbations et à donner aux responsables le temps de s'adapter au nouveau langage.

Pourquoi certains mainteneurs s'opposent-ils à l'intégration de Rust dans le noyau ?

Alors, si Rust est si génial, pourquoi cette controverse ? Certains mainteneurs affirment que la multiplicité des langages rende plus difficile la maintenance du noyau. Selon eux, l'utilisation de plusieurs langages est une « complication indésirable et risquée ». Voici une analyse des principaux points de désaccord :

• la maintenabilité : certains mainteneurs, dont Christoph Hellwig, s'inquiètent de la maintenabilité à long terme du code Rust dans le noyau. Selon eux, l'introduction d'un second langage ajoute de la complexité et pourrait conduire à des incohérences ;
  
• qualité du code : certains mainteneurs se demandent si le code Rust dans le noyau sera aussi efficace et idiomatique que le code C, en particulier lors de l'interface avec le code C existant et les structures de données du noyau ;
  
• autorité du mainteneur : si Linus Torvalds passe outre les objections des mainteneurs, cela pourrait saper leur autorité et créer des conflits au sein du processus de développement ;
  
• gestion de la base de code : l'introduction d'un autre langage dans le noyau peut poser des problèmes de gestion. La réécriture constante de parties d'un langage à l'autre peut poser problème.
  

Christoph Hellwig craint que les bindings Rust (le code qui relie Rust et C) ne s'infiltrent partout comme un cancer, conduisant à un projet fragmenté avec des lignes directrices floues. Le mainteneur craint également les frais généraux liés à la gestion d'un projet multilingue.

Source : Christoph Hellwig, mainteneur du noyau Linux

Et vous ?

Quel est votre avis sur le sujet ?
Linus Torvalds pourrait passer outre le veto des mainteneurs et fusionner le code du noyau Rust. Qu'en pensez-vous ?

Voir aussi

Que pensent les développeurs du noyau Linux de Rust ? Le langage est pour d'aucuns une opportunité de combler les faiblesses du C en sécurisation de la mémoire des logiciels et un cancer pour d'autres

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

Le mélange de Rust et de C dans Linux est assimilé à un « cancer » par un responsable du noyau, « je ne veux pas qu'il s'approche d'une énorme base de code C que je dois maintenir », dit-il à propos de Rust

[d_d_v]

Et qui ferait ça? un débutant en programmation Rust?

En Rust, on évite de programmer en unsafe, quand on est un programmeur confirmé. D'une part, parce qu'on maitrise le paradigme de programmation safe par défaut, d'autre part parce qu'on a appris à minimiser l'usage d'unsafe.

J'avais écrit sur un autre fil que seuls les incompétents ou très très débutants écrivaient du c++ avec une écriture non "sécurisée" (pas de conteneurs STL, pas de shared pointeurs), et on m'a répondu qu'on ne pouvait pas faire confiance dans le développeur. Je ne vois donc pas pourquoi il en serait autrement en rust. Ca fait plus de 20 ans que j'ai travaillé sur plusieurs projets, et à chaque fois, dès que des facilités non recommandées sont offertes dans le langage, il y a toujours des gens qui les utilisent. Ca peut être quelqu'un d'incompétent, ou alors pour corriger un problème en quatrième vitesse en mettant un TODO qui restera ad vitam æternam dans le code, par exemple, ou alors un développeur qui se barre du projet dans une semaine et qui bacle ou sabote le code avant de partir.
Tu peux être sûr et certain, que si une facilité existe, elle sera utilisée, quel que soit le langage.

[smarties]

Là le dilemme est légitime :
- d'un côté on a les développeurs C qui qui font et ne documentent rien
- de l'autre on a un langage proche mais sécurisé qui force presque à écrire du code de qualité

De toute façon, introduire le Rust ne se fera pas sans "douleur", il y aura probablement des ratés au début comme tout nouveau changement. Mais quand les anciens développeurs C sont pas éternels, qui pourra alors maintenir ?

[Uther]

J'avais écrit sur un autre fil que seuls les incompétents ou très très débutants écrivaient du c++ avec une écriture non "sécurisée" (pas de conteneurs STL, pas de shared pointeurs), et on m'a répondu qu'on ne pouvait pas faire confiance dans le développeur.

Ce qui fait toute la différence entre Rust et C++ au niveau de la sécurisation, c'est qu'elle est opt-in en C++ alors qu'elle est opt-out en Rust.

Même si l'on considérait que la STL et les smart pointers sont memory safe (ce qui n'est pas le cas), il faudrait toujours s'assurer de bien les employer, tout le temps. En C++, quand on sort des clous par erreur, le plus souvent, rien ne nous l'indique. Il ne s'agit pas que d'un problème de débutant, même un développeur expérimenté finit par faire des erreurs, car il n'y a pas de démarcation précise entre ce qui est sûr et ce qui ne l'est pas.

En Rust, par défaut, tout est sécurisé d'un point de vue mémoire. il est peu probable d'écrire unsafe { x.get_unchecked(i) } en toute lettre, sans que l'auteur ne se rendre compte qu'il est en train de faire quelque chose de potentiellement dangereux, et que le relecteur n’identifie immédiatement le risque. Si on travaille avec des gens auquel on ne fait pas assez confiance (qui n'ont probablement pas besoin de code unsafe), il y a moyen de verrouiller son usage dans le projet, ou forcer à documenter chaque utilisation pour expliquer ce qui permet de vérifier que l'utilisation est correcte.

[fdecode]

dès que des facilités non recommandées sont offertes dans le langage, il y a toujours des gens qui les utilisent. Ca peut être quelqu'un d'incompétent, ou alors pour corriger un problème en quatrième vitesse en mettant un TODO qui restera ad vitam æternam dans le code, par exemple, ou alors un développeur qui se barre du projet dans une semaine et qui bacle ou sabote le code avant de partir.
Tu peux être sûr et certain, que si une facilité existe, elle sera utilisée, quel que soit le langage.

L'unsafe n'est pas vraiment une facilitée. C'est contraignant; c'est repérable; on doit réfléchir au préalable à la manière de s'en servir correctement...
Une facilité serait plutôt de cloner toutes les données en lecture seule afin de limiter l'usage de références non mutable et d'éviter le conflit avec une référence mutable.
Cela simplifie les choses, mais c'est sous optimal. Par contre, c'est parfaitement sûr.

[djm44]

Il me semble qu'il est possible d'écrire un code exact en C ou dans un autre langage. Beaucoup de
publicités sont faites sur ce langage Rust auquel je n'adhère pas. Il y a déjà une profusion de langages
qui nuit à la simplicité des approches . Chez Mozilla c'est Rust, chez Google c'est Go, chez Apple c'est Swift. Sur le
web c'est Java, JavaScript, PHP.

Et finalement le mieux c'est encore le C ou mieux encore le C++ à mon avis vu le nombre de codes existants . Linus Torvalds devrait passer au C++ mais il a une aversion pour ce langage ce qui le pousse vers Rust. Quand quelqu'un dit quelque chose de vraie cela l'est non pas parce qu'il le dit en Français ou en Anglais.

[Uther]

Il me semble qu'il est possible d'écrire un code exact en C ou dans un autre langage.

En théorie, avec des développeur parfait, oui. Mais dans la pratique, même les meilleurs développeurs font des erreurs. L'historique de Linux parle de lui-même : 1020 CVE pour des erreurs de corruption mémoire ont dû être corrigées l'année dernière. Utiliser un langage qui empêche par défaut certains types d'erreurs dont la corruption mémoire est un gros avantage.

Beaucoup de publicités sont faites sur ce langage Rust auquel je n'adhère pas. Il y a déjà une profusion de langages qui nuit à la simplicité des approches . Chez Mozilla c'est Rust, chez Google c'est Go, chez Apple c'est Swift. Sur le web c'est Java, JavaScript, PHP.

Le terme publicité est très mal adapté. Rust a ses défenseurs qui apprécient ses qualités, mais il n'est pas la propriété d'une société qui aurait besoin qu'il soit largement adopté pour l'écosystème qu'elle distribue comme Apple avec Swift, ou Microsoft avec C#.
Mozilla à participé aux débuts du langage, mais il n'en a jamais particulièrement fait la promotion. Rust était déjà un projet indépendant de la fondation Mozilla lors de sa sortie officielle, il y a dix ans. Ca fait un moment que la contribution de Mozilla à Rust est anecdotique.

Et finalement le mieux c'est encore le C ou mieux encore le C++ à mon avis vu le nombre de codes existants . Linus Torvalds devrait passer au C++ mais il a une aversion pour ce langage ce qui le pousse vers Rust.

Ce qui fait que le Rust a été choisi là ou d'autres ont été écarté, c'est parce qu'il apportait des garanties de sécurités(contrairement au C++), sans sacrifier les performances et le contrôle du bas niveau (contrairement à la plupart des langages sûrs).