Il vont taper make au lieu de make…Envoyé par 23JFK
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Il vont taper make au lieu de make…
Il se raconte que la communauté Rust est imbuvable et arrogante (un peu en mode nous sommes l'avenir - mais avenir qui n'arrive pas vraiment à faire ses preuves). Je ne sais pas vraiment ce qu'il en est, mais ce dont je suis est certain, c'est que mélanger deux langages aussi différents pour un projet aussi complexe et dont le but est l'accessibilité open-source est absurde d'autant que les promesses de sécurité améliorées ne sont pas vraiment au rendez-vous et probablement plus théorique que réelle (de mon point de vue) quand il faut être au plus près du hardware. Au niveau kernel, il n'y a de place que pour un seul langage (ou deux langages très semblables type C/C++). Si l'objectif était de faire une transition douce en remplaçant progressivement du C par du Rust, ça ne peut pas fonctionner et un mix éternel ne sera pas viable. Ça va finir par un fork du kernel où il y aura une version 100% en C, et une version à x% de Rust en progression... fragile.
Ça pourrait ne pas être aussi simple.
C'est vrai qu'une partie de la communauté Rust peut parfois être un trop enthousiaste et certains le déclarent un peu trop vite comme le langage inéluctable de l'avenir. Mais la majorité de la communauté ne soutient pas ça et travaille à limiter la diffusion de ce genre de propos. Il y a notamment des règles dans les canaux de discussion officiels contre ce genre de prosélytisme.
Mais en matière d'imbuvabilité et d'arrogance, la communauté Rust n'a absolument rien à envier aux communautés C et C++, qui à l'inverse se targuent bien trop souvent d'être les gardiennes du temple du bas niveau, qu'elles seules ont le droit de cité dans le domaine, et critiquent Rust souvent sans en savoir grand chose. Et pour le coup il ne semble pas y avoir beaucoup de volonté pour modérer ce genre de propos.
Dire que les promesses de sécurité ne sont pas au rendez-vous, c'est juste votre jugement personnel au doigt mouillé qui ne coïncide pas avec le mien.
Du peu de faits qu'on a pu constater pour le moment, il n'y a pas encore eu de problèmes mémoire remonté dans les drivers Linux écrits en Rust et selon les retours de Ashai Lina, la développeuse qui maintient le plus gros driver Rust pour le moment (GPU pour Apple Silicon), le langage l'a énormément aidée à développer rapidement du code de qualité. Évidement ça reste beaucoup trop tôt pour tirer des conclusions formelles dans un sens comme dans l'autre..
Tant qu'on garde une séparation claire avec une API bien définie, il n'y a pas vraiment de soucis. Seul les drivers peuvent être écrits en Rust, le cœur du noyau reste en C, et il n'y a aucun plan pour changer ça. Si un jour on voulait introduire du Rust dans le noyau lui même, la situation serait en effet compliquée, mais rien de tel n'est prévu.
Pour le moment si, en tout cas pour lancer la compilation, ça ne change rien foncièrement si on utilise pas de drivers en Rust.
Évidement si on veut activer des drivers en Rust, ça pousse à rajouter le compilateur à la chaine d'outils, mais pour le coup elle contient déjà entre autre Perl et OpenSLL, donc on peut pas dire que le problème de bloat de la chaine soit nouveau.
Avec un Makefile bien fait, tu peux compiler un logiciel développé avec différents langages sans problème. Linux est en C et en assembleur et pourtant un simple make suffit à le compiler sans te soucier du fait qu’il y a deux (maintenant 3) langages. (Voire un de plus avec les Kconfig qu’il faut interpréter)
Pour Rust au cœur du noyau ? Il semble que Rust dispose de pas mal de constructions permettant de s’interfacer avec du C, et ce de manière plus simple que d’autres langages et leur FFI.
Mais pour éviter de dupliquer les efforts, il faudrait utiliser cbindgen… pas sûr qu’il fonctionne bien avec les header Linux… à tester…
Rust permet en effet de s'interfacer avec du C mais pas aussi simplement qu'avec du C++, qui lui même n'est pas 100% transparent. Même si des outils comme bindgen et cbindgen peuvent aider, il reste pas mal de problèmes éventuels.
Les premiers exemples de problèmes qui me viennent en tête
- le typage avancé de Rust dont certaines propriétés sont perdues quand on passe au C
- certains choix pertinent dans un langage le sont moins quand on passe à l'autre. Par exemple en Rust il arrive qu'on utilise une référence à un objet car le borrow checker assure sa validité, alors qu'en C on aurait fait une copie pour éviter les risques.
- si l'interface entre les parties en C et en Rust doit être modifiée trop souvent (et il me semble avoir lu qu'il y a régulièrement des changements internes), ça va être lourd à maintenir.
Et c'est évidement loin d'être exhaustif. Pour que ça se fasse bien, il faudrait au minimum que tous les développeurs noyaux soient tous de très bons développeurs C et Rust.
L'avantage de limiter Rust aux drivers c'est que c'est des modules qui n'ont pas impact direct sur le code noyau et qui ne sont pas généralement pas trop impactés par les changement du noyau. L'interface entre le noyau et les drivers est bien définie et ne devrait pas changer tous les jours.
@Uther petite question sur quelque chose que je n'ai pas bien compris:
- pas mal de gens disent que Rust n'a pas d'ABI stable, ce qui est très handicapant si l'on se retrouve à devoir passer par l'ABI C pour faire des bibliothèques partagées
- cependant, ' extern "Rust" ' fait bien parti de la doc et aucune mention de potentiel problème avec elle, ni de limitation avec la création de .dll/.so
Du coup, les bibliothèques partagées en Rust, ça donne quoi ?
En effet l'ABI "Rust" de base n'est pas stable, ce qui fait qu'on évite le plus souvent les bibliothèques partagées au format Rust car elles ne sont compatibles qu'avec les programmes compilées avec la même version du compilateur. C'est pour cela que le compilateur Rust lie statiquement par défaut.
Si on veut une DLL qui puisse s'interfacer avec d'autre langages, on peut forcer l'utilisation de l'ABI du C qui est stable, via extern "C" pour les fonctions et #[repr(C)] pour les types. L'inconvénient est que forcément on perd les possibilités offertes par le typage Rust qui n'ont pas d'équivalent en C.
extern "Rust" n'est malheureusement pas une solution. Ça indique juste explicitement d'utiliser l'API Rust instable, ce qui revient à la mème chose que ne pas utiliser extern du tout.
Si jamais tu as absolument besoin de DLL qui marchent quelque soit la version du compilateur, il faut malheureusement pour le moment te restreindre à l'API C. Je sais qu'il y a des crates comme stable_api et stabby qui essaient d’émuler une API Rust stable au travers de l'ABI C, mais je ne les ai pas utilisée, je ne sais pas ce que ça vaut.
c'est surtout que dans l'écosytème des distrib ou de gros projet divisé en sous produit, on distribue des bibliothèques partager pour ne pas recompiler la moitié des libs pour une correction mineure.
C'est donc une contrainte à garder à l'esprit et qui demande réflexion
- soit accepter de partir sur une version LTS et y rester à moins qu'un changement significatif en vaille le coup. C'est en vrai un choix qui s'entend pour un projet avec une porter réduite, j'ai vu des appli encore utiliser GCC 4.8 ou 4.9 de mémoire, alors que la versions 9 était disponible de moins presque 1 an et proposait les sanitizer (bon dieu, ce que leur aide me manque sous windows). Mais un compilateur introduit rarement de faille et le changer en cours de risque, c'est prendre des risques de régression (ou de se rendre compte que du code marchait parce que le compilo avaient un comportement non standard)
- soit accepter de tirer les dépendances nécessaire et de les lier statiquement à chaque appli. De nos jour, on a beaucoup de RAM et d'espace de stockage, l'économie que ça permettra ne vaut certainement pas le coup et ça n'est pas ingérable sur un projet privé.
- soit ne passer que par de l'ABI C pour contourner l'ABI Rust, mais cela complexifie l'usage
C'est pas mal rebutant pour motiver le passage de libs en Rust
C'est pas vraiment ce qui est encouragé par l'écosystème Rust qui n'a pas de version LTS et sort une nouvelle version toutes les 6 semaines. La rétrocompatibilité étant plutôt bien assurée, et la montée de version étant facile via l'outil standard d'installation du compilateur (rustup), on a tendance à changer facilement pour la version la plus récente du compilateur.
C'est en effet la façon standard de faire en Rust. L'outil standard de build et gestion de dépendances (cargo), fourni de base avec le compilateur, rend ce mode de fonctionnement très simple et efficace.
Il tire les dépendances depuis le dépôt central "crates.io" (ou éventuellement un dépôt git spécifique), les recompile automatiquement et les lie statiquement.
En général on ne fait ça que si on veut que si on veut que la bibliothèque soit utilisable dans d'autres langages ou si on veut mettre en place un système de plugin. Dans ce cas là on a pas le choix, l'ABI C étant l'interface commune utilisée par quasiment tout les langages pour permettre d'interagir entre eux.
Non, le "C" permet de tout faire, y compris les couches que rajouteraient les langages de plus haut niveau pour sécuriser la mémoire.
La sécurisation de la mémoire dépend essentiellement du programmeur et des outils qu'il a mis en place. Avoir des fonctions d’allocations sécurisé est très facile à faire. Faire du bound checking , de la détection de mémory leaks ou d’overwrite en temps réel est aussi très simple à mettre en œuvre en ‘C’.
Développer des langages pour intégrer une partie du travail (sécurisation) ou de l’organisation (++) du développeur est une perte de temps monumental pour l’informatique au sens large.
Enfin, Il faut savoir reconnaitre les "butter soft". le "C", seul langage élaboré par un ingénieur est un "butter product" . On ne met pas à jour le beurre, on ne le remplace pas, on ne l'améliore pas.
Pour des systèmes de plugins, je vois un peu de WASM.
Permettre de tout faire, ne veut pas dire que c'est l'outil idéal pour tout faire. Si tu veux rajouter assez de couches au C pour le sécuriser aussi bien que Rust, tu vas juste créer un nouveau langage.
C'est d'ailleurs plus ou moins comme ça qu'est né Rust, quand Mozilla s'est rendu compte que sécuriser complètement le C++ introduisait tellement de limitations et d'incompatibilités avec l'existant que c'était plus efficace de faire un nouveau langage.
C'est tellement simple que, même dans les OS, les bases de données et les navigateurs dont la sécurité est particulièrement surveillée, plus des deux tiers des vulnérabilités sont causées par des erreurs mémoires.
C'est en effet une perte de temps quand on a sa disposition une armée de développeurs de génie, parfaitement formés et surtout qui ne font jamais la moindre erreur.
Mais dans le monde réel, ça n'est pas une perte de temps.
C’est un peu ce que l’on reproche au C. Il fait reporter une charge au programmeur qui pourrait être automatisée et rendue plus fiable. Oui, C permet de comparer un indice et une taille de tableau… donc permet le bound checking mais on n’est pas à l’abris d’un oubli. Il n’y a pas d’annotation ou «*pragma*» permettant de rendre le bound checking implicite en tapant a[i]=2.
Tu penses à quel outil ? Lint, SonarQube, … pas sûr que cela détecte autant qu’un compilateur associé à un langage intégrant la sécurité.
En poussant l’argument, on pourrait se contenter de programmer en langage machine (même pas en langage assembleur). L’évolution des langage a justement pour but d’intégrer une partie du travail du programmeur.Développer des langages pour intégrer une partie du travail (sécurisation) ou de l’organisation (++) du développeur est une perte de temps monumental pour l’informatique au sens large.
En effet WASM est une technologie intéressante pour un système de plugin vu que ça apporte aussi le sandboxing. Par contre, c'est plus complexe a mettre en œuvre qu'un simple chargement de bibliothèque dynamique, ça a un impact sur les performances et on va aussi avoir des limitations au niveau de l'API.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager