Rust ne pourra évidement pas résoudre tous les problèmes, mais ce qui fait son intérêt au niveau de la sécurité, c'est justement qu'il contrait à appliquer certaines règles qui sont juste des bonnes pratiques en C et C++, où l'on peut les violer aussi bien par méconnaissance que par erreur.

Rust ne pourra évidement pas résoudre tous les problèmes, mais ce qui fait son intérêt au niveau de la sécurité, c'est justement qu'il contrait à appliquer certaines règles qui sont juste des bonnes pratiques en C et C++, où l'on peut les violer aussi bien par méconnaissance que par erreur.

"utiliser les ressources (matérielles ou humaines) au max" c'est la définition de l'exploitation, ni plus, ni moins.

" Un employé signe un contrat d'échange de ressources contre un salaire, il est libre de mettre fin à ce contrat quand il veut" -> pure lecture de droite d'une personne qui pense qu'en traversant la rue on trouve du boulot 🤣

"Pour connaitre des artisans qui bossaient dans les années 60 ils faisaient bcp moins de chantiers dans l'année et partaient à la retraite bien avant 60 ans. "

C'est possible même si ce n'est pas le retour de ceux que je connais (je suis du milieu) mais surtout ce n'est pas le sujet, tant mieux si on pouvait moins travailler à l'époque mais c'est une question d'économie globale pas une question de modernisation de l'outil de travail.

"Les machines n'ont pas été développées pour soulager les travailleurs mais pour augmenter la productivité..."

Oui c'est précisément la raison pour laquelle je réponds dans le message précédent "Et c'est de facto le cas", comme l'histoire des machines agricoles et de l'esclavage. Il se trouve que dans ce cas l'intérêt des entreprises rencontre l'intérêt des employés.

"...et permettre d'exploiter les gens plus longtemps"
Pure lecture partisane de gauche qui n'a aucun sens. L'objectif d'une entreprise est de faire du pognon et par extension de réduire au max ses charges financières dont les salaires des employés si ceux-ci sont moins productifs qu'une machine mais pas particulièrement de les "exploiter", d'ailleurs je t'invite à bien réfléchir à la notion d'exploitation qui est plus complexe à définir qu'il n'y paraît. Un employé signe un contrat d'échange de ressource contre un salaire, il est libre de mettre fin à ce contrat quand il le veut.

*"Effectivement on utilisait du "vieux C++", les choses ont évolué en C++. Mais pas toutes les bases de codes, tout le monde n'a pas envie de faire du C++ moderne, et n'est pas obligé.
C'est une des raisons pour laquelle je préfère Rust, il y a une contrainte de "qualité de code" supérieur."*

Mais ne pas faire de C++ moderne, sauf cas particulier, est idiot ! C'est comme utiliser de l'essence au plomb alors qu'il y a mieux.
La qualité d'un code ne dépend pas d'un langage mais du développeur. En revanche qu'on se sente plus à l'aise avec Rust ou le C++ pour faire un code de qualité, c'est plus une question de goût et de couleur.

La qualité d'un code ne présume absolument pas de sa fiabilité. Voici un bon exemple : https://github.com/RustCrypto/block-ciphers. Autant de dire qu'utiliser ce code dans autre chose qu'un projet de hobbyiste, c'est prendre des gros risques.
Pourquoi ? Car Rust ne peut pas garantir l'execution en temps constant ni l'assembleur produit.
Ce qui fait la confiance d'une libraire, ce n'est pas uniquement la qualité de son code. J'ai bien plus confiance dans BLAS que dans n'importe quelle code, quand bien même Rust garanti l'absence de bug mémoire dans son implémentation.


*"Le rapport que je fais, c'est que dans les deux cas c'est le moyen d’accéder à une allocation mémoire.
Si le C++ moderne incite à ne plus utiliser directement les pointeurs, c'est encore possible, et très présent dans les bases de code historique."*

Je reformule ma question. En quoi un Mutex est un access à la mémoire ? Sémantiquement ça ne fait pas de sens.

"En Rust (non Unsafe) il n'y a pas de pointeur, une allocation mémoire est encapsulé dans un objet qui contraint (et explicite) la façon dont on pourra accéder à la donnée (modification ou pas, multi-thread ou pas"

Oui comme en C++ avec le concept du RAII. Alors certes, on n'a pas les même garanti que Rust à la compilation, mais on les a à l'execution.

Le vieux C++ doit disparaître des codes et surtout de l'enseignement de la programmation aux nouvelles générations. Le vieux C++ est révolu et ne doit perdurer que les endroits où les MaJ d'un code n'est pas simple et sans conséquence.

Comparer Rust SO avec TIOBE ne renseigne pas sur la même information. TIOBE fonctionne sur "Le nombre de pages web retournées par les principaux moteurs de recherche lorsqu'on leur soumet le nom du langage de programmation". Donc clairement à l'échelle du Web, on parle moins de Rust que des autres langages, pourtant personne ne nie que Rust à le vent en poupe.

Pour SO, comparer Rust, Javascript et Python me laisse dubitatif sur les questions posés. bref, ce genre de sondages a la même valeur que "80 % des sympatisants d'un parti politique sont pour Mr X à la tête du parti". Et pourtant Mr X se prendre une branlée aux élections présidentielles.

Pour le jeux vidéo, où verrais-tu l'usage de Rust ?

" (en dehors des usages ou la compilation est un problème, type "scripting dynamique" par exemple)."

En dehors du HPC, de toute approche parallèle plus complexe qu'un fork-join, de la crytographie, du jeux vidéos... Rust est très bon là où la sécurité mémoire est critique (e.g, équipement réseau, pare-feu, noyau...). Mais si la sécurité mémoire n'est pas une priorité, Rust devient moins utile/interessant comme solutions.

"Et sur quoi tu te bases pour dire que Rust est nettement moins répandu que Python ?"

La faible migration de projet vers Rust (les offres en C++ sont largement supérieure à Rust en France). Le faible classement dans l'index TIOBE, et le fait que le C/C++ domine toujours depuis 10 ans alors que Rust peine encore à prendre la place.
Quand Python est arrivée, en 10 ans il a pris la place de Matlab, IDL et consort dans les milieux académiques et industrielle. Matlab est encore enseigné dans les écoles d'ingénieurs au coté de Python mais de plus en plus de prof. passe à Python. Idem pour les universités.
Quand à Rust, bah il commence à sortir le bout de son nez.

Tu parlais du Rust dans le jeu vidéo. Je ne l'ai pas vu détroner significativement le C++ dans ce domaine. En revanche, j'ai vu Python faire office d'alternative à Lua.

"En Rust le type indique l'intension et les contraintes lié à une allocation mémoire, alors qu'en C/C++ on a juste un pointeur."

Et par curiosité, quelle version du C++ tu utilises ? Parce que je suis d'accord pour le "vieux C++". Mais ce n'est plus le cas avec le C++ moderne. Les pointeurs ne sont plus censé se trimballer seul maintenant, et surtout, sauf cas particulier, on en a rarement besoin.

Ah oui, mélanger la notion de pointeur en C avec celle du C++, c'est pas comparable. Le pointeur C et C++ sont sémantiquement la même chose, mais la manière de les utiliser à largement changer.

"L'exemple qui me vient en premier est les pointeurs en C/C++ vs Rc, RefCell, Arc, Mutex, RwLock en Rust."

C'est quoi le rapport entre un pointeur et Arc, Mutex et autres ? On mélange des choux et des carottes là, non ?

Plutôt d'accord avec toi.

Je rajouterai des éléments qui font que, pour moi, Rust restera un langage assez cloisonné dans ses usages.

Déjà, la syntaxe. On a beau avoir de l'expérience et connaitre plus ou moins un certain nombre de langage, il est très difficile de lire et comprendre un tant soit peu du code Rust sans aucune connaissance du langage. Et ce n'est pas un langage facile. Il vient avec de nombreuses "contraintes" qui sont le pendant de la sécurité de la gestion de la mémoire. Tous les développeurs ne sont pas près à faire ça. Il suffit de voir encore tous ceux qui préfèrent faire du javascript au lieu du typescript !! (purtant, la marche technique me semble beaucoup moins haute)

De plus, il existe déjà des langages beaucoup plus sûr que le C, mais sans avoir le même modèle que le Rust. Je pense à l'Ada notamment. Pourtant, l'Ada n'a pas percé non plus, sauf dans des zones de niches. Et ça fait plus de 40 qu'il existe et qu'il évolue ! (Ada83, Ada95, Ada2005, Ada2012 et Ada2023)

Ensuite, et là c'est un avis strictement personnel, j'ai trouvé que l'API manquait un peu de cohérence et de clarté. Et avec cargo, on peut vite se retrouver avec le syndrome NPM : 1 dépendance en rajoute 50.

Enfin, je n'ai rien contre Rust pour de nouveaux projets. Mais inclure Rust dans des projets déjà existant comme le noyau Linux, c'est le meilleur moyen, à mon sens, de créer des problèmes. L'homogénéité au sein d'un projet, notamment un projet de cet envergure, devrait être la priorité. Le débogage pourra être extrêmement pénible, car il faudra à la fois avoir des connaissance sur le fonctionnement du noyau, en C et en Rust (et des connaissances plus ou moins poussées). L'attrait pour de nouveaux contributeur pourrait aussi en pâtir, tant la marche technique peut sembler élevée pour contribuer.

La Californie est démocrate. Je ne vois pas trop pourquoi il n'y aurait pas d'équivalent pour ce camp.
Kamala Harris a aussi exercé en Californie (procureure puis procureure générale) et était sénatrice de Californie avant de devenir vice-présidente.

oui voilà, et ils se trompent mutuellement de toute façon.
Mais c’est vrai que l’idée est clairement pas limpide, my bad