Rust est un langage de programmation développé principalement par Mozilla. La première version stable, la 1.0, est sortie en 2015. La dernière version disponible à ce jour est la 1.46.0, publiée le 27 août 2020.
Dépourvu de ramasse‑miettes, il permet une gestion fine de la mémoire, de manière sécurisée pour prévenir les erreurs de segmentation. Il garantit aussi la sécurité des fils d’exécution (thread safety). Ces caractéristiques en font un langage sûr et performant.
Ses bonnes performances, comparables à celles du C et du C++, le rendent particulièrement adapté à la programmation système. Ainsi, il est utilisable dans un grand nombre de situations où ces deux langages étaient habituellement utilisés : noyau de système d’exploitation, services de systèmes, embarqué, moteurs de jeu vidéo 3D, etc.
Cette dépêche se propose de revenir sur son histoire, courte mais riche, et d’examiner la situation présente.
Sommaire
- Retours sur les évolutions de Rust depuis sa sortie
- Des chiffres !
- À qui s’adresse Rust ?
- Adoption de Rust
- En conclusion
Retours sur les évolutions de Rust depuis sa sortie
Rust a été largement couvert sur LinuxFr.org, à travers les versions 0.7, 0.8, 0.9, 0.10, 0.11, 0.12, 1.0‑alpha.
Le 15 mai 2015, la première version stable de Rust était publiée 1.0, les versions 1.1, 1.2 et 1.3, l’édition 2018. L’année 2020 marque les cinq ans du langage, et à cette occasion la fondation Mozilla a publié un récapitulatif des principales améliorations (EN) portées au langage !
En cinq ans le langage a donc beaucoup évolué, la version 2018 étant la dernière traitée sur LinuxFr.org une petite mise à jour s’impose.
En 2019
1.33 — Le Pinning : il est parfois utile d’avoir la garantie qu’un objet ne bougera pas en mémoire, comme un objet ayant un pointeur sur lui‑même qui serait invalidé en cas de changement d’adresse. Le type Pin assure que les données pointées par n’importe quel pointeur de type P ont une adresse stable, la donnée ne peut pas bouger ou être désallouée jusqu’à ce qu’on enlève le Pin. La donnée est dite « pinned ».
1.34 — Des dépôts de Crates alternatifs pour Cargo : le Rust est de plus en plus utilisé en production, il y a un besoin grandissant de dépôts privés. Cargo a toujours permis des dépendances via Git mais avec les Alternative Registries (EN) une organisation peut facilement créer et partager son propre dépôt de crates, d’une façon similaire à crates.io (EN).
1.39 — Async/Await, le futur est là : la stabilisation des mots clefs async et await était une des tâches majeures pour faire de Rust un langage de premier ordre. Tout juste six mois après sa libération, la programmation asynchrone se développe en un écosystème diversifié et performant. Notamment avec Tokio (EN) !
Pour utiliser async-await, il faut commencer par ajouter async devant une fonction :
async fn first_function() -> u32 { .. }À la différence d’une fonction ordinaire, un appel à une async fn retourne un Future. C’est une opération en suspend qui attend qu’on lui dise de s’exécuter. Pour exécuter un future on utilisera l’opérateur .await :
async fn another_function() {
// Create the future:
let future = first_function();
// Await the future, which will execute it (and suspend
// this function if we encounter a need to wait for I/O):
let result: u32 = future.await;
...
}Dans cet exemple, on utilise future.await en lieu et place de await future dans la plupart des langages, cela permet une meilleure intégration avec le mot clef « ? » pour la gestion d’erreur. Vous pouvez simplement écrire future.await ?.
Contrairement à d’autres langages l’implémentation des futures en Rust est dite sans coût, en effet les futures de Rust ne font rien à moins d’être interrogés. Dans d’autres langages, appeler une fonction asynchrone lance un futur qui commence à s’exécuter immédiatement. Pour plus de détails (EN) !
En 2020
1.42 — Subslice patterns : ce n’est pas le plus grand changement du langage mais c’était une fonctionnalité depuis longtemps attendue qui va améliorer le confort des développeurs et l’expressivité de la recherche de motifs (pattern matching). L’introduction du « rest pattern » permet de vérifier la correspondance avec le reste d’un slice grâce au mot clef .. , comme dans cet exemple :
fn foo(words: &[&str]) {
match words {
// Ignore everything but the last element, which must be "!".
[.., "!"] => println!("!!!"),
// `start` is a slice of everything except the last element, which must be "z".
[start @ .., "z"] => println!("starts with: {:?}", start),
// `end` is a slice of everything but the first element, which must be "a".
["a", end @ ..] => println!("ends with: {:?}", end),
rest => println!("{:?}", rest),
}
}Cette liste n’est, bien entendu, pas du tout exhaustive, le langage s’est continuellement amélioré sur le plan de la stabilité, des performances et des fonctionnalités. Le compilateur est plus performant et un peu moins pointilleux, de nouvelles macros sont apparues, pour faciliter le débogage par exemple et tout un tas de petites fonctionnalités s’additionnent pour hisser le langage à un autre niveau. Le blog officiel en expose le détail (EN) !
Une autre grande annonce de 2020 est la création d’une fondation pour le langage. Créé et poussé par la Fondation Mozilla depuis ses débuts, le langage s’offre une fondation en propre, la Rust Fondation (EN). Au‑delà des difficultés rencontrées récemment par Mozilla c’est avant tout une manière de rendre le projet plus autonome et indépendant des décisions d’un seul groupe.
Des chiffres !
En 2018, le dépôt Rust (EN) sur GitHub compte plus de 87 000 commits et plus de 2 200 contributrices et contributeurs. Au niveau des statistiques spécifiques à GitHub, le projet est suivi par plus de 5 400 personnes et a été marqué d’une étoile par plus de 32 000 personnes.
Il y a plus de 28 000 dépôts sur GitHub (EN) utilisant le langage Rust. Pour comparaison :
- 1 428 dépôts lors de la sortie de la version 0.10 ;
- 3 262 dépôts lors de la sortie de la version 0.12 ;
- 4 892 dépôts lors de la sortie de la version 1.0‑alpha ;
- 7 000 dépôts lors de la sortie de la version 1.0.
Toujours en 2018, Open Hub compte 650 projets en Rust, plus de 7 300 contributrices et contributeurs, près de 350 000 commits et plus de 11 300 000 lignes de code. Pour comparaison :
- 121 projets lors de la sortie de la version 0.10 ;
- 165 projets et 1 007 386 lignes de code lors de la sortie de la version 0.12 ;
- 200 projets et 1 200 000 lignes de code lors de la sortie de la version 1.0.
Ces chiffres montrent que depuis mai 2015 l’intérêt pour Rust a fortement crû. En 2020, le dépôt Rust (EN) sur GitHub compte plus de 125 000 commits.
À qui s’adresse Rust ?
Rust s’adresse aussi bien aux développeurs C et C++, qu’aux développeurs de langages de plus haut niveau qui souhaiteraient s’initier à la programmation système sans avoir à affronter les galères de gestion de la mémoire ou de gestion de dépendances. Il a trois avantages majeurs par rapport au C et au C++ :
- il empêche les problèmes d’accès concurrents à la mémoire, le code est alors facile à paralléliser, même dans des bases de code très volumineuses ;
- grâce à son système de type évolué, il évite la plupart des bogues liés à la gestion de la mémoire que l’on retrouve dans un grand nombre de CVE de systèmes critiques : use‑after‑free (utilisation de [la mémoire] après [sa] libération), double free (double libération), iterator invalidation (invalidation d’itérateur [lors du parcours d’un tableau]) ou encore un débordement de tampon (buffer overflow). Cette vérification s’effectue essentiellement à la compilation, mais certaines vérifications additionnelles sont également effectuées à l’exécution (bound‑checking (contrôle des bornes) sur les tableaux) ;
- il dispose de fonctionnalités modernes dont ne disposent pas des langages plus anciens : une gestion simple et intuitive des dépendances (via l’outil
cargo) et des fonctionnalités issues de la programmation fonctionnelle (pattern‑matching,map(),filter(),reduce(), etc.), entre autres.
De plus, puisqu’il ne nécessite pas d’environnement d’exécution, il est facile à interfacer avec des projets écrits dans d’autres langages comme Python (EN) ou Go, dans le but de bénéficier du maximum de performances sur une partie critique du code. Par exemple avec cette bibliothèque (EN) qui utilise le moteur d’expressions rationnelles de Rust depuis Go, améliorant significativement les performances par rapport à la version de la bibliothèque standard Go.
Il existe d’ailleurs des bibliothèques qui permettent de faire facilement le lien entre le Rust et d’autres langages : Ruru (EN) ou Helix (EN) pour le langage Ruby ; Neon (EN) pour écrire des modules natifs rapides et sûrs pour Node.js, la plate‑forme événementielle en JavaScript côté serveur ; PyO3 (EN) et milksnake (EN) pour le langage Python ; Bindgen (EN) pour les langages C et C++.
Adoption de Rust
Rust a mis toutes les chances de son côté, mais ses chances étaient bien minces de percer tant le problème est ardu. L’intérêt des informaticiens pour un langage de haut niveau performant et « sûr » est réel mais, pour les convaincre, il faut arriver à avoir un gain suffisant de performances par rapport à Python et un gain significatif dans la facilité de programmation par rapport au C++ sans être trop différent afin d’être adopté facilement.
La sortie de Firefox 56 avec l’intégration de code Rust a propulsé l’intérêt du langage. Les performances du navigateur ont prouvé ses capacités. On sait maintenant qu’il est possible de coder en autre chose qu’en C/C++ avec des performances similaires pour le programme final. En juin 2020, 12 % de Firefox (EN) étaient codés en Rust.
De la même manière Discord bascule de Go à Rust pour son écosystème de bibliothèques, notamment en matière d’asynchronisme avec Tokio (EN), sa gestion mémoire et ses performances globales.
En plus de ces avantages techniques purs, comme un gestionnaire de paquet et de construction quasiment magique : Cargo (EN), le langage peut également compter sur un écosystème de bibliothèques foisonnant (crates de leur petit nom, publiées sur crates.io (EN)) et qui est, de plus, de très bonne qualité.
De nombreuses distributions GNU/Linux ont empaqueté le compilateur Rust et Cargo, ainsi que différentes applications développées en utilisant Rust. Par exemple, Debian propose depuis sa dernière version stable (Buster), ripgrep (EN), exa (EN) ou encore fd (EN).
Certains projets comme Actix (EN) ou Alacritty (EN) démontrent les performances du langage, l’un en se hissant en haut du
Web Framework Benchmarks (EN) de TechEmpower, passant même devant des cadriciels en C ou C++, tout en proposant des fonctionnalités de très haut niveau comme les closures, de l’asynchronisme ou du pattern matching !
D’autres projets comme Bevy (EN), un moteur de jeu 2D/3D multi‑plate‑forme sur le modèle Entité‐Composant‐Système) bien que très jeunes se constituent rapidement une belle communauté (EN), signe qu’il y a une appétence des développeurs pour le langage.
Le langage creuse aussi son trou dans d’autres projets où on l’attend moins, comme npm (EN), qui l’utilise en plus du JavaScript, ou bien Deno (EN), un possible successeur de Node.js (EN).
Par ailleurs, il a été question d’intégrer du Rust dans le noyau Linux. L’idée pourrait attirer de nouveaux développeurs qui ne veulent pas forcément faire du C (EN).
En conclusion
Que dire ? Le Rust est élégant, bien construit, dispose de fonctionnalités de haut niveau tout en restant très performant et même s’il a encore quelques lacunes, par exemple en ce qui concerne les interfaces graphiques (avec cependant de bons candidats (EN)), il n’en demeure pas moins très stable et tout à fait utilisable.
Récemment, les développeurs derrière Chromium et Chrome ont publié un billet (EN) concernant la possible utilisation de Rust au sein de leur base de code, soulignant les gains ainsi que les défis que cela représente dans le cas très pointu et particulier qui est le leur.
Pour avoir une petite idée de ce à quoi ressemble l’écosystème de Rust, vous pouvez consulter cette liste (EN) qui recense des applications, bibliothèques, outils et ressources jugées impressionnantes.
Le langage est encore jeune, mais il promet, et le plus simple pour vous faire un avis c’est de l’essayer ! Allez sur le site officiel (EN) du projet qui a une très bonne documentation, des cours et un « Book » (EN) très agréable à lire.
Si vous préférez avoir du papier entre les mains, on trouve de bons bouquins ; par exemple, en anglais, chez l’éditeur O’Reilly : Programming Rust, 2nd Edition et The Rust Programming Language (Covers Rust 2018), ou chez Eyrolles, en français, Programmer avec Rust.
Vous pouvez même directement l’essayer en ligne si ça vous dit (EN) !
Aller plus loin
- Rust en 2018 (34 clics)
- Liste et évolution des contributeurs pour chaque version publiée (16 clics)
- Réécriture en Rust d’outils courants en ligne de commande (80 clics)
# Rust dans Linux
Posté par erdnaxeli (site web personnel) . Évalué à 10. Dernière modification le 03 septembre 2020 à 11:30.
À noter que le sujet d'intégrer du Rust dans Linux (le kernel) a été évoqué récemment : https://lkml.org/lkml/2020/7/9/952. Ça serait un signe supplémentaire je pense pour la crédibilité de ce langage, si certain en doutait encore.
L'idée ça serait aussi d'attirer de nouveaux développeurs qui ne veulent pas forcément faire du C : https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Rust dans Linux
Posté par Aldebaran (site web personnel) . Évalué à 5.
Ouaip ça aurait pu être dans la dépêche, peut être qu'un ou une modo pourra l'ajouter ? Je n'étais pas au courant, c'est intéressant quand on se rappel ces mot de Linus au sujet du C++.
[^] # Re: Rust dans Linux
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 6.
Rajouté à la fin de la partie sur l'adoption de Rust. Je n'ai, par contre, pas ajouté ce qui concerne Linus Torvalds et le C++.
Oh et merci pour le boulot que tu as fait pour finir cette dépêche.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Rust dans Linux
Posté par cosmocat . Évalué à 7.
Y'a des articles sur Phoronix assez récent sur le sujet:
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Rust-Path-LPC2020
https://www.phoronix.com/scan.php?page=news_item&px=Torvalds-Rust-Kernel-K-Build
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Plumbers-2020-Rust
De de que j'ai compris:
[^] # Re: Rust dans Linux
Posté par Aldebaran (site web personnel) . Évalué à 1.
De rien j'avais envie de participer depuis longtemps :) Merci à toi pour la modération !
[^] # Re: Rust dans Linux
Posté par ZeroHeure (site web personnel) . Évalué à 5.
Sauf erreur de ma part, Linus ne fait pas le lien entre Rust et les nouveaux développeurs.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Rust dans Linux
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
https://hackaday.com/2020/07/15/will-2020-be-the-year-of-rust-in-the-linux-kernel/ dit, à juste titre :
Mais le mieux est d'aller voir les discussions https://lore.kernel.org/lkml/CAKwvOdmuYc8rW_H4aQG4DsJzho=F+djd68fp7mzmBp3-wY--Uw@mail.gmail.com/T/ Pour moi, il en ressort que ce ne sera pas pour le cœur du noyau (car il y a des choses que ça ne sait pas encore faire et que c'est rédhibitoire) mais peut-être pour des pilotes, et encore il faut que ce soit plus stable (car même pour GCC on ne court pas après la dernière version et on veut des trucs stables sur une dizaine d'années.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Anglicisme
Posté par Anthony Jaguenaud . Évalué à 4.
J’ai noté ce petit anglicisme.
[^] # Re: Anglicisme
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
# Pffff
Posté par rewind (Mastodon) . Évalué à 3.
C'est saoulant à force de toujours se comparer à C ou C++. Je veux dire, la liste des langages qui allaient tuer C et C++ est longue comme un jour sans pain, peut-être que Rust en fera partie un jour également. Ou peut-être qu'il vivra sa vie à côté de C et C++. Quand on lit la dépêche, on a vraiment l'impression que tous les développeurs C et C++ rêvent de passer à Rust. Ce n'est pas le cas, certains (dont moi) sont très content de leur paquet de Bonux. Les utilisateurs de langages de programmation ne sont pas un marché à se partager !
Quant aux qualités de Rust, elles existent. Mais le choix d'un langage ne dépend jamais des qualités du langages uniquement (un des langages les plus populaires en ce moment est Javascript…). L'écosystème compte énormément. Et le poids de l'existant également. Et C++ est en train de rattraper son retard sur Rust sur tout un tas d'aspect et a plein de qualités également.
[^] # Re: Pffff
Posté par barmic 🦦 . Évalué à 10.
Il me paraît logique de comparer le langage avec les 2 références de son domaine de prédilection (la programmation système et la performance). Ça ne fait pas toujours plaisir, mais c'est ça d'être celui qui est en place.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pffff
Posté par Aldebaran (site web personnel) . Évalué à 4.
Exactement, ce n'est pas parce qu'on le compare aux tauliers du game qu'il va les remplacer hein !
Je vais me la jouer Nostradamus mais je ne vois pas le C et le C++ être remplacés avant très, très longtemps. D'ici là on se déplacera en aéroglisseur.
Moi aussi je fais du C et du C++, et j'aime ça, j'aime aussi beaucoup le Rust et je pense qu'en avoir fait un peu m'a permit de devenir un meilleur dev C++. Y a des machins que je n'utilisais pas en C++ (par ignorance ou fainéantise), comme les pointeurs intelligents par exemple. Maintenant oui, mais je ne me suis penché dessus qu'en cherchant à comprendre comment marchait le borrowing en Rust.
C'est une alternative, personne ne force personne mais (de mon avis éclairé et impartial) le Rust ça dépote. Ça peut faire une corde de plus à son arc c'est toujours ça !
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Qu'est-ce qui a été rattrapé?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par Thomas Douillard . Évalué à 3. Dernière modification le 04 septembre 2020 à 10:31.
Se débarrasser d’une tonne d’historique crade pour faire du propre directement, c’est quand même une promesse d’aller plus vite et pousser aux bonnes pratiques sans incitations à se réfugier dans les coins sombres par les 8000 manières de faire de C++, dont bien des manières de se tirer une balle dans le pied. De quoi se sentir bien plus léger …
[^] # Re: Pffff
Posté par rewind (Mastodon) . Évalué à 3.
Le principal avantage de Rust, c'est-à-dire l'analyse de l'utilisation de la mémoire pour éviter des erreurs. Il y a eu un papier et depuis, MSVC et Clang on implémenté l'idée de ce papier (
-Wlifetimepour Clang) pour faire tout un tas de vérifications à la compilation. Alors, certes, ce n'est pas activé par défaut, ce n'est pas encore dans GCC, mais ce n'est qu'une question de temps.[^] # Re: Pffff
Posté par Thomas Douillard . Évalué à 2.
Intéressant, ça se compare comment par rapport à ce que fait Rust à ce sujet ?
[^] # Re: Pffff
Posté par Guillaume Knispel . Évalué à 7. Dernière modification le 07 septembre 2020 à 01:49.
J'irais pas jusqu'à dire que ça a rattrapé Rust. Wlifetime est un espèce linter optionnel heuristique (unsound) proposé par certains compilateurs. Le check des lifetimes de Rust est ultra fondamental, mandatory, sound, et intégré au système de type.
Je ne sais pas si Wlifetime est utile en pratique, j'espère que oui, mais perso j'ai pas essayé. Mais sans intégration au système de type et soundness on pourra jamais dire qu'il a complètement rattrapé Rust. Or c'est pas vraiment la direction que souhaite prendre le C++ pour le moment (la solution de Rust étant trop contraignante pour faire évoluer des bases de code sans parfois des refactoring majeur, et sera probablement toujours perçu comme trop contraignante par certain programmeurs et/ou pour certaintes routines; les solutions moins contraignante le restent néanmoins beaucoup sur ce même aspect, et relèvent de toute manière pour l'instant du domaine de la recherche).
Et vu le langage et les objectifs usuels des migrations vers Rust, AMA ça serait pas une bonne idée que le C++ cherche à "rattraper" frontalement ce genre de caractéristiques. Il y a des problèmes pratiques qui sont difficiles à résoudre dans les projets potentiels (cf. les réflexions de Google et de MS), et il suffit que le C++ propose d'autres features en plus d'être suffisamment bon pour se placer dans une situation ou c'est en pratique économiquement compétitif de réduire la densité de bugs (en particulier des bugs susceptibles d'avoir des conséquences catastrophiques en stabilité et sécurité) en continuant en C++ que ce qui pourrait être fait en migrant des bouts vers Rust.
Mais si tu veux vraiment absolument un check de lifetime fiable et que c'est totalement critique, tu fais clairement du Rust plutôt que du C++ même avec Wlifetime, et je vois vraiment pas ça changer, du moins pas avant très longtemps (et même dans très longtemps, je pense que ça a une très faible proba que le C++ "rattrape" complètement le Rust sur ce point).
[^] # Re: Pffff
Posté par xcomcmdr . Évalué à 8.
Oui bah moi je suis bien content qu'un langage tel que Rust soit ENFIN là pour faire du natif, sans me taper toutes les erreurs que le C amène à faire (à moins d'être à moi seul l'équivalent de l'Android Security Team ou celle de MS… ce qui est impossible), et avec toute l'expressivité d'un langage moderne.
Il garantit même que je n'aurais pas de data races. Même C# ne fait pas ça (oui y'a les analyzers de Microsoft mais c'est juste des warnings par défaut et il faut les rajouter sur chaque projet…).
Je vais enfin pouvoir lâcher mon langage préféré (C#, même s'il est open-source), et même s'il tente de corriger le tir (en .NET 5 il est enfin possible d'avoir des points d'entrée pour le natif, ou avec CoreRT on peut carrément le compiler en natif et se passer du GC et de la compilation JIT… mais tout cela est trop expérimental pour le moment).
Le C est mort, vive le C. Vive Rust.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
On pouvait déjà faire du natif sans C: Pascal, Ada et plus récemment Go.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par xcomcmdr . Évalué à 1.
Techniquement oui, mais Rust est le seul qui prend de l'envol aujourd'hui (Ada, qui l'utilise ?), n'est pas super bizarre à utiliser / mort (Pascal), m'horripile avec ses goroutines et sa syntaxe et son approche (Go).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par CrEv (site web personnel) . Évalué à 10.
C'est surtout que Go a déjà pris son envol il y a plusieurs années :-)
Sinon du code en Ada ça existe pas mal (aviation, ferroviaire). C'est moins tendance et plus sur une niche mais c'est pas pour autant que c'est mort.
[^] # Re: Pffff
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
On trouve même encore des offres d'emploi pour de l'Ada et dans d'autres, c'est considéré comme un réel atout de connaître (ça sent le portage vers C++ ceci dit) :)
Bon, ok, c'est dans les domaines que tu cites, donc oui, c'est de la niche.
[^] # Re: Pffff
Posté par btd . Évalué à 2.
Je confirme, il y a d'ailleurs une bonne raison pour ça, dans le ferroviaire tout au moins : pour que les systèmes aient le droit d'exister (comprendre : faire rouler des trains dans la vraie vie, avec des vrais gens dedans, qu'on peut blesser ou tuer si les systèmes déconnent), ils doivent être certifiés en regard d'une, voire de plusieurs normes.
Et s'agissant du logiciel, la norme en question (EN50128) indique une liste de langages utilisables pour ce genre de développements, en indiquant un statut : "Highly Recommended" (i.e. les certifs c'est toujours pénible, mais tu marques des points), "Recommended" (i.e. sers-toi en si tu veux, mais tu vas galérer), "Not Recommended" (i.e. n'y pense même pas).
L'Ada est catégorisé HR, le C est R. Pas infaisable donc, mais 'achement plus pénible en fait.
[^] # Re: Pffff
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 10.
Sachant que les domaines principaux où il y a de l'Ada sont le spatial et l'aéronautique, je pense qu'Ada prend beaucoup plus souvent son envol que Rust pour le moment :)
[^] # Re: Pffff
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
A mon avis, C a virer Ada dans pas mal de code qui vole.
"La première sécurité est la liberté"
[^] # Re: Pffff
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
Ben, dans les hélicoptères Tigre et NH90, c'est toujours de l'Ada sur certains matériels
Sur le Boeing 777, c'est de l'Ada aussi et on en trouve aussi dans l'A-380.
Ça ne vole pas mais ça aide, le serveur de gestion du trafic aérien européen est, en partie, codé en Ada.
Je ne suis donc pas aussi sûr que toi de ton assertion
[^] # Re: Pffff
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Je connaissais des gens de MBDA, ils disaient que les codeurs Ada étaient rares, et que c'était plus simple en C.
"La première sécurité est la liberté"
[^] # Re: Pffff
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 07 septembre 2020 à 11:28.
Ça, c'est vrai. Le C, on en trouve partout donc ça vaut le coup de savoir coder en C => pas de pénurie de codeurs C
Le langage Ada est plus complexe, peut-être aussi complexe que le C++ et on en trouve que dans des marchés de niche donc il y a peu d'intérêt à en faire => pas beaucoup de développeurs Ada
Perso, je remarque un peu plus de mouvement sur StackOverflow autour d'Ada ces derniers temps mais cela reste confidentiel. Au passage, la qualité des réponses aux questions est excellente :)
[^] # Re: Pffff
Posté par Meku (site web personnel) . Évalué à 3.
Difficile d'évaluer l'activité Ada réelle étant donné le type de marché de niche qu'il occupe :
- Les programmes de défense seront plus confidentiels.
- Les projets utilisent généralement des licences GNAT Pro, payantes mais incluant de base un support technique de haute qualité et très réactif. Dans ces cas là, c'est plus simple de poser des questions (même pour du support en programmation) directement à AdaCore plutôt que StackOverflow, et donc ça ne se voit pas sur le web.
[^] # Re: Pffff
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Certes mais cela donne au moins une idée pour ce qui est du ressort du hobby.
[^] # Re: Pffff
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
Et hop, c'est tombé hier, le code de certains composants d'un des prochains prototypes de drone d'Eurocopter sera en Ada sous VxWorks (source).
Comme quoi, ça bouge encore :)
[^] # Re: Pffff
Posté par xavier philippon . Évalué à 10.
Ada est utilisé dans dans des environnements où le code doit être sécurisé. C'est le cas du spatial, du militaire ou de l'aviation.
A ma connaissance, les militaires surveillent de très près l'évolution de Rust car c'est un langage intrinsèquement sécurisé. Pour le moment, on bute sur la certification des compilateurs mais dès que ce détail sera levé, il y a de grandes chances pour que tout un pan de l'industrie logicielle bascule vers Rust.
[^] # Re: Pffff
Posté par anaseto (site web personnel) . Évalué à 3.
Après, je ne suis pas sûr que ce soit juste un détail : atteindre un niveau de confiance suffisamment élevé pour se porter garant qu'un compilateur aussi complexe que rustc+llvm n'introduit pas de bugs, c'est improbable et, pour l'instant, il n'y a pas de compilateur alternatif plus axé sur la correction, il me semble.
[^] # Re: Pffff
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Des compilateurs certifiés, je n'en connais qu'un seul. vu que les compilo C sont utilisa sans certifications, il y a moyen de moyenner (méthodologie de test du code produit, etc… )
"La première sécurité est la liberté"
[^] # Re: Pffff
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Au passage, si ça intéresse, y a toute une page là-dessus pour ce qui est de la "pub" et une page plus technique chez Adacore.
On parle bien sûr de certification pour des domaines donnés comme l'aéronautique et pas de compilateur certifié.
En dehors de CompCert, point de salut en ce concerne le certifié sans bug :)
[^] # Re: Pffff
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
adacore s'engage maintenant pour la certification ? Ils sont dans le processus, ou est-ce que tu te débrouille seule avec l'instance de certification ?
"La première sécurité est la liberté"
[^] # Re: Pffff
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Là, j'en sais rien, je bosse pas pour eux (ils n'ont pas voulu de moi ;))
A lire sur le site, je ne crois pas qu'il faut se débrouiller seul.
Après tout, c'est un éditeur pas une société de conseil.
Et puis, c'est facile de certifier, non ? :)
[^] # Re: Pffff
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Il fallait lire
[^] # Re: Pffff
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Go sacrifie un peu les perf pour beaucoup de simplicité, trop de simplicité parfois. Il y a donc de la place pour un truc un peu plus hardcore; avec gestion de la mémoire à la main.
"La première sécurité est la liberté"
[^] # Re: Pffff
Posté par barmic 🦦 . Évalué à 3.
Au moins par défaut, la mémoire n'est pas vraiment gérée à la main. Il n'a pas de garbage collector, mais ça reste une gestion automatique de la mémoire. Comme le RAII de C++ (sauf que c'est tout à fait optionnel en C++).
std::mem::forgetn'est pas sensé être systématiquement utilisé.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Comment Rust gère les cas non triviaux de libération de la mémoire (ce qu'un bon compilo pour langage à garbage collector peut gérer automagiquement) ? Par exemple une structure de type graphe ou récursive?
En les interdisant?
https://github.com/rust-lang/rfcs/issues/415
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par barmic 🦦 . Évalué à 1.
Rien compris à cette phrase.
Je ne sais pas. Je dis juste que rust gère la mémoire automatiquement, même s'il n'utilise pas de gc pour ça. Tu n'a pas a libérer manuellement ce que tu as alloué sur le tas. Qu'il y ai des contraintes c'est tout à probable, le gc aussi posent des contraintes.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
En analysant le code, on peut éviter d'utiliser le ramasse miette pour les allocations / désallocations les plus courantes.
Si tu as un code simple comme:
function postCoincoinDuJour() {
let linuxfr = new LinuxfrBoard();
let message = "Coincoin du " + new Date().getDay(Lang.FR);
linuxfr.post("Coincoin");
}
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par Thomas Douillard . Évalué à -1.
Il n’y a pas de ramasse miette dans Rust. Tu veux parler du tas ? Ou tu trolles juste comme un goret.
[^] # Re: Pffff
Posté par xcomcmdr . Évalué à 2.
C'est exactement cette page (The stack and the Heap) qui répond à ta question :
https://doc.rust-lang.org/1.22.0/book/first-edition/the-stack-and-the-heap.html
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Donc Rust fait juste comme C++ et ses smart pointers?
Je comprends mieux le ticket pour ajouter un ramasse miette à Rust.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par xcomcmdr . Évalué à 3. Dernière modification le 06 septembre 2020 à 10:15.
Je ne saurais te répondre, je suis encore en train de découvrir Rust.
Tu aurais un exemple en Java que je pourrais traduire en Rust pour voir ?
(note : je suis pas expert, mais tu as piqué ma curiosité)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Ce qui me vient en tête immédiatement, c'est un code qui manipule des graphes.
En java ou C, je vais avoir des classes ou structures Graph, Edge et Node.
En C, il faudra faire bien attention à passer free partout, au bon moment et dans le bon ordre.
En C++, on va choisir avec soin quelles références seront des unique_ptr, des shared_ptr ou des weak_ptr selon les cas d'usage.
Avec un ramasse miette, chacune peut avoir des références sur les autres, on ne va pas se préoccuper de la durée de vie des objets, des pointeurs forts ou faibles… Osef on a de la RAM et le GC passera le balai !
Et avec Rust ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par xcomcmdr . Évalué à 3.
Euh, les fuites mémoires à cause d'évènements ou d'objets non-disposés (utilisant des connexions à des bases de données, des ressources réseau, des Span, …), ça arrive et ça fait mal.
C'est l'une des raisons de l'introduction des WeakReference et du Weak Event Pattern en C# il y a fort longtemps.
(Pour Rust ce commentaire te répond mieux que moi :
https://linuxfr.org/nodes/115151/comments/1823387 ainsi que ses réponses)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par barmic 🦦 . Évalué à 2.
Tu as bien plus drôle à faire : utiliser des lambda comme callback sans te rendre compte que ce que tu capture dans ta fermeture. Ça touche tous langages objet qui a des lambdas et personne ne peux rien pour toi. C++ est peut être un peu mieux loti car il rends explicite la capture, mais pas au point de voir quel objet est dans la capture.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
J'ai rarement eu besoin des weak references et à chaque fois c'était pour des ressources systèmes (les textures dans Newton Adventure par exemple :-) ) qui de toute façon demande une gestion particulière.
Est-ce qu'il ne vaut pas mieux un langage avec un GC pour 99% des allocations et gérer à la main le 1% qui reste?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par xcomcmdr . Évalué à 2.
Le prob du GC c'est qu'il stoppe le monde quand il fait son boulot.
Alors souvent c'est imperceptible, parce que tout est fait pour qu'il soit ultra rapide (on ferait pas des applications de bureau qui tournent à 60 FPS comme avec WPF par exemple sinon. Exemple : Visual Studio), mais bon.
C'est pas super pour un jeu vidéo, par exemple.
L'autre "problème" des langages managés en termes de perfs c'est le JIT (compilation à la volée). Alors y'avait dejà NGEN, ReadyToRun ou autre pour contourner plus ou moins ça mais ça reste partiel.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Les premiers GC stoppaient le monde. Les modernes travaillent de façon incrémentale et parallèle.
Beaucoup de jeux utilisent un langage à ramasse miettes sans problème: tous les jeux Java, html5, Unity, Lua…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par barmic 🦦 . Évalué à 2.
Les derniers aussi. Ils sont plus efficaces, mais oui le stop the world existe toujours.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Aujourd'hui les vraies pauses sont si petites qu'on ne les remarque plus (CTB !).
Il y a même un GC pauseless pour Java, mais il n'est pas libre :(
Note aussi que le temps d'exécution des autres modes de libération de la mémoire n'est pas NULL non plus.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par barmic 🦦 . Évalué à 1.
Dépend des usages, ça. ZGC qui est monstrueux annonce 2ms, ce qui est bien trop important pour un jeu vidéo temps réel.
Je n'ai jamais essayé azul zing.
Ils ne bloquent jamais toute l'application, ils sont totalement prédictibles, ils ne prennent pas de temps CPU hors de la libération de la mémoire,…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Comme dit plus haut, regarde le nombre de jeux écrit avec un langage à GC.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par barmic 🦦 . Évalué à 5.
Tu veux dire le nombre de jeux qui utilisent un gc en frontend ? Oui il y en a pas mal, mais il n'y a aucune contrainte pour ce genre de code. Ce n'est pas la prouesse de leur gestion mémoire qui permet ça, mais leur capacité à s'interfacer avec du code natif. C'est pour ça qu'on trouve lua par exemple.
Pour parler de java, je doute que l'on trouve une application dont la mémoire est crucial qui ne fasse pas du off the heap.
C'est comme dire que la gestion mémoire de python est sacrément bonne parce que si on utilise numpy ça déchire. C'est moins sa gestion mémoire que la qualité de son interface avec du natif que l'on estime.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Je ne sais pas trop ce que tu veux dire par "en frontend", mais beaucoup de jeux utilisent un langage GC comme langage principal et pas seulement comme langage de script.
Regarde ce qui se fait avec les cadriciels Java (libgdx, lwjgl), Python (pygame), C# (monogame, Unity), Lua (Löve).
L'accès aux API graphique/sonore/inputs se font toujours en C, mais la majorité du code et donc des allocations mémoires sont pris en charge par le GC.
Pourquoi ces jeux sont fluides et n'ont pas de gros ralentissements dû à un ramasse miette Arrête Le Monde? Parce que d'une part, comme je l'ai déjà dit, les GC modernes ramassent les mettes de façon incrémentales et concurrentes, d'autre part les développeurs de jeux font la chasse aux allocations/désallocations en pré-allouant un maximum de choses, en utilisant des pools, en préférant des tableaux fixes aux hashmaps dynamiques…
Cette chasse est faite aussi dans les jeux en C/C++, car comme je l'ai déjà dit aussi, les malloc/free, c'est coûteux pour tout le monde, pas seulement quand c'est un GC qui les fait.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par barmic 🦦 . Évalué à 3.
libgdx, pygame,… sont en C ou C++ plus qu'en python ou java quand ce n'est pas simplement sdl qui fait toutes la partie critique en terme de perf par exemple
Parce que la mémoire n'est pas géré par le garbage collector. Quand ut garde une taille de heap petite ça fonctionne bien.
Qu'il y ai des optimisations possibles on est d'accord, mais elles ne peuvent pas tout. Tu ne peux pas allouer directement un objet en old generation par exemple ce qui permettrait de ne pas voir ton gc passer des objets que tu sais qu'ils ne sont pas à détruire.
Je crois que l'allocation mémoire est plus coûteuses en natif que dans la JVM qui gère déjà sa mémoire vis à vis de l'OS.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . Évalué à 3. Dernière modification le 08 septembre 2020 à 14:50.
Logique ce sont des bindings, mais une bonne partie du code est quand même dans le langage à GC. Avec le code des jeux qui l'utilisent, ça fait une majorité du code final sous GC.
Logique aussi, une bonne partie de la mémoire dans un jeu, ce sont les vertices, les shaders et les textures qui ne sont même pas en RAM et qu'il faut de toute façon gérer à la main, GC ou pas GC.
Il y a aussi beaucoup d'autres données, par exemple le moteur physique qui lui bombarde bien la RAM et là aussi il faut optimiser à coup de préallocations et de piscines. GC ou pas.
Bref les GC modernes ne sont pas un problème dans les jeux. Ni dans les applis web, ni dans 99% des applis. Il faut simplement ne pas te rater quand tu es dans le 1% des cas qui demande une gestion manuelle.
Ca ne veut pas dire que les GC sont une meilleure approche que les "pointeurs intelligents", mais juste une solution plus simple et plus générale.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 08 septembre 2020 à 15:17.
Ça n'est pas la partie critique.
On ne les utilise pas dans les parties critiques donc ce n'est pas un problème ? Soit.
Dis autrement ce n'est pas une question de performance des gc qui permet ça. Juste qu'on a construit des frameworks pour dissocier la partie critique de l'application. C'est une très bonne chose, hein pas une critique du tout.
Là c'est encore très différent. Pour un deamon qui aura par nature une durée de vie plus longue, c'est bien plus simple d'utiliser un gc pour limiter la fragmentation mémoire. Mais même comme ça les appli qui ont une certaine criticité vont faire du off the heap.
De mon avis perso, « 99 % des appli » devraient plus s'intéresser à la correction qu'à la performance et donc éviter à tout prix de manipuler à la main la mémoire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
C'est souvent utilisé dans le moteur physique qui est critique.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par barmic 🦦 . Évalué à 2.
Je ne connais pas.
Pour les pool d'objets dont tu parlais plus haut, c'est tout de même assez relou à faire. Tu reconstruit un fonctionnement à la malloc/free avec tous les problèmes qui vont avec (use after release, fuite mémoire,…) et ton pool ne doit pas être un point de contention vu que tu va l'utiliser sur une partie du code plutôt stressée.
Je crois que ça peut être plus propre en C++ en utilisant un allocateur personnalisé (c'est transparent à l'usage tant que tu utilise du RAII).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Ça me rappelle ce nourjal https://linuxfr.org/users/devnewton/journaux/veuillez-instancier-ce-journal-avant-de-le-lire !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par barmic 🦦 . Évalué à 2.
C'est discutable. Le JIT a beaucoup plus d'info que la compilation AOT pour faire ces choix et ce n'est pas quelque chose de continue aucun langage managé que je connais ne compile du code continuellement (sinon c'est plus proche d'un code interprété en fait), une fois que le JIT est passé, c'est juste du code natif qui s'exécute. Si ton jeu s'exécute peu de temps ça pose un problème, mais sinon ça ne fait pose pas tant de problème que ça.
Je pense que c'est plus la gestion de la mémoire qui pose problème (les gc créent un overhead en consommation mémoire, ça demande un certains tunning d'avoir un gc qui s'exécute correctement sur du temps réel comme ça,…).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pffff
Posté par xcomcmdr . Évalué à 0.
C'est vrai, perso j'ai jamais eu de problème à cause du GC ou du JIT, en .NET on est vachement bien loti de ce côté là.
Mais en même temps je n'ai jamais écrit de jeu vidéo.
Peut-être en aurais-je en .NET 5 pour émuler un jeu vidéo en étant appelé par la libretro (Native Callable Exports), mais vu que je vise la Megadrive, j'en doute (et au pire je passe à CoreRT ou à Rust).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par xcomcmdr . Évalué à 2. Dernière modification le 08 septembre 2020 à 16:41.
Sauf qu'il a vachement moins de temps pour compiler qu'un compilateur AOT, donc d'améliorer les performances.
En revanche, avec de l'AOT tu perds les API de Reflection (voir: CoreRT).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pffff
Posté par GuieA_7 (site web personnel) . Évalué à 4.
Du côté de l'AOT, les techniques de Profile-guided optimization et autre AutoFDO permettent de réduire cet avantage du JIT ; il reste au JIT la possibilité de générer du code natif différent si 2 exécutions ont des profiles très différents.
Mais je serai curieux de savoir si en pratique cet avantage mène souvent à des différences de performances significatives.
[^] # Re: Pffff
Posté par GuieA_7 (site web personnel) . Évalué à 5.
Une façon idiomatique en Rust de gérer les structures de données complexes consiste à utiliser des index plutôt que des pointeurs (les objet étant stockés dans une collection classique). J'ai cru comprendre que Rust fonctionne bien avec les systèmes à entités (ECS) du coup.
Mais oui dans certains cas on va avoir recours à des smart pointers ; un truc cool c'est que le compilateur va nous obliger à utiliser un compteur atomique (ARC) si on partage des objets entre plusieurs threads (on peut donc utiliser un comptage de référence classique plus performant dès que possible, sans peur de ne pas être thread-safe).
Mais via les cycles de référence il est tout à fait possible d'avoir des fuites de mémoires ; et donc un GC optionnel aurait du sens en effet.
[^] # Re: Pffff
Posté par jeberger (site web personnel) . Évalué à 1.
Rust ne permet pas de faire des cycles de références (hors code
unsafe), sauf à utiliser des pointeurs faibles (Weak), il n'est donc pas possible d'avoir des fuites de mémoire (du moins pas plus qu'avec un ramasse-miettes).[^] # Re: Pffff
Posté par GuieA_7 (site web personnel) . Évalué à 5.
Tu te trompes :
https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
(première ligne: "Rust’s memory safety guarantees make it difficult, but not impossible, to accidentally create memory that is never cleaned up (known as a memory leak").
Comme le dit le lien que j'ai indiqué, les pointeurs faibles servent à casser les cycles ; ils sont donc la (une) solution, pas le problème.
[^] # Re: Pffff
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
On fait ça aussi en C ou en C++. C'est parfois utile, mais ça ne change pas le problème: au lieu de faire attention à mes pointeurs, je dois faire attention à mes indexes.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pffff
Posté par GuieA_7 (site web personnel) . Évalué à 4.
(préambule: je ne suis pas un codeur Rust expérimenté, et serai donc bien incapable de tenir un débat trop technique là-dessus—mais l'avis d'un spécialiste m'intéresse aussi)
[^] # Re: Pffff
Posté par mothsART . Évalué à 7.
Effectivement, plusieurs langages ont échoués dans cette tâche.
Là ou Rust se distingue d'autres langages c'est qu'il n'utilise que des algos éprouvés (d’où la rouille) alors que des langages plus académiques (OCAML, Haskell etc.) ont plus servi de POC.
La guideline de départ du langage était claire : remplacer C++ dans Firefox pour améliorer les soucis de mémoire et de concurrence.
Tous les développeurs C et C++ rêvent de passer à Rust : clairement, non. Ceux qui ont de la bouteille dans un langage, on foncièrement plus de difficultés à en changer. Ils ont appris à éviter les pièges et par conséquent l'intérêt est moindre.
En revanche, un jeune dev aura plus facile à s'orienter vers Rust à mon sens et des projets avec un mix senior/junior demande moins d'efforts de review des seniors car le compilateur fait plus de vérifs.
L'écosystème compte également : je trouve que pour un langage, au départ soutenu par aucune GAFAM, Rust a fait son bonhomme de chemin a ce niveau.
Pour ce qui de Javascript c'est plus lié au fait qu'il y a beaucoup de dev web et que ce langage est incontournable. (mais, c'est volatile : le vent va peut-être changer avec webassembly et/ou Typescript)
Pour ce qui est des évols de C++ : si je ne me trompe pas, rien n'est déprécié donc un projet peut très bien mélanger du C++ old school avec des concepts plus récents ?
Vu de l’extérieur (j'ai pas fait suffisamment de C++ pour avoir un avis objectif) : Le poid de l'existant est très lourd en C++ et l'on peut faire la même chose de mille et une façon.
La rétrocompatibilité à tout prix c'est un vrai soucis à plusieurs niveaux.
[^] # Re: Pffff
Posté par abriotde . Évalué à 2.
Oui enfin, très peu on duré plus de 6 mois. Rust conquiert chaque année du monde. En dernier, Linux (qui avait rejeté le C++… ). D'ailleurs tu vante le C++, mais il n'a pas supprimer le C, pourtant il s'est imposé. Ce qu'on dis c'est que Rust est en train de d'imposer.
Remplacer C, ne veux pas dire supprimer C. Mais au moins prendre une part de C ce qu'aucun à part C++ n'a réussit. Si C doit disparaître ce sera pas avant 50 ans et sans doute bien plus on en convient.
[^] # Re: Pffff
Posté par rewind (Mastodon) . Évalué à 6.
Je te conseille de relire l'histoire du langage D (qui continue de bouger un peu).
Alors je le répète, l'utilisation des langages de programmation, ce n'est pas un marché à se partager. C'est une vision totalement erronée. Déjà parce que plein de gens pratiquent plusieurs langages, et que ce n'est pas parce qu'un langage gagne des utilisateurs qu'il faut nécessairement qu'un autre en perde. C est très loin d'être mort, il est encore utilisé dans tout un tas d'endroit, et il a tout un tas de qualité que Rust n'a pas. Idem pour C++.
[^] # Re: Pffff
Posté par GuieA_7 (site web personnel) . Évalué à 4.
Tu as quelques pépites sous le coude ? C'est sûrement parce que je m'intéresse beaucoup à Rust (et pas spécialement à D), mais j'ai l'impression que je vais avoir pas mal de briques en Rust dans ma distro Linux d'ici quelques temps (en plus de celles qu'il y a déjà), mais pour D, à part un shoot'em libre que j'avais testé y a quelques années ça n'a pas l'air d'être trop ça.
J'aimerai bien que tu développes, parce que pour le coup je ne suis pas entièrement d'accord. Je peux boire plusieurs types de soda, et même plusieurs types de cola, Koka et Paipsi sont quand même concurrents et se partagent un marché. Si on considère les nouveaux projet démarrés, j'imagine qu'on peut envisager l'ensemble des langages, dans lequel on va choisir, comme un marché ; et ce même sans tout percevoir de manière consumériste de manière générale.
[^] # Re: Pffff
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Pour apporter de l'eau à ton moulin, ni Java ni ObjectiveC ou autres n'ont vraiment remplacé C++ C'est en fait cette tendance à vouloir faire des comparaisons à la con qui m'agace le plus : les deux langages n'adressent pas les mêmes points, donc il ne sert à rien ces jeux puérils de qui-a-la-plus-grosse. Chacun peut exister par lui-même, pour ses qualités et ses spécificités (et faiblesses)
:-)“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pffff
Posté par barmic 🦦 . Évalué à 5. Dernière modification le 05 septembre 2020 à 01:02.
Une comparaison n'est pas une compétition. Il n'y a rien de con à comparer des langages. Observer des approches différentes et leurs impactes. S'inspirer des autres langages est nécessaire. Rust étant utilisé à des endroits où C ou C++ règnent en maîtres depuis plusieurs décennies c'est difficile de ne pas en parler. Mais encore une fois C++ n'a pas tué C, rust ne tuera pas ses prédécesseurs. Je ne vois pas pourquoi s'en offusquer.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Pffff
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Nous disons la même chose… (je crois) Le mal n'est pas de comparer des approches mais de vouloir mettre en compétition (c'est le but de nombreuses comparaisons et de commentaires disant que tel langage est supérieure à tel autre.) Oui, on peut apporter de l'air frais et mieux faire dans des contextes bien définis (qui correspondent finalement au cahier des charges de la conception/naissance) sans pour autant tuer les précédents.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Concernant le switch Discord
Posté par woffer 🐧 . Évalué à 4.
Visiblement, la comparaison ne semblait pas très juste car basée sur une vieille version de Go (cf. le tweet du leader technique de Go Russ Cox https://twitter.com/_rsc/status/1224802726774812672?s=20).
[^] # Re: Concernant le switch Discord
Posté par barmic 🦦 . Évalué à 5.
Ce a quoi ils ont répondu qu'ils ont bien vu, mais qu'ils ne veulent plus avoir de garbage collector https://medium.com/@jesse_11222/we-tried-several-go-versions-595626d34076
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Rust dans Windows
Posté par Glandos . Évalué à 6.
Non, franchement, je n'ai pas envie de faire de pub pour Windows, mais il se trouve que Microsoft envisage d'utiliser Rust dans Windows. D'ailleurs, il y a une bibliothèque pour WinRT et quelques autres projets.
Ça mettrait quand même Rust bien en avant, ne serait-ce que pour l'introduire dans les connaissances recherchées chez les développeurs.
[^] # Re: Rust dans Windows
Posté par Pierre Jarillon (site web personnel) . Évalué à -4.
Vu que Rust est disponible sous Lnux, quand ce sera fait, ce sera une raison de plus pour se passer de Windows.
# Rust is everywhere
Posté par cosmocat . Évalué à 10.
https://science.slashdot.org/story/20/09/03/2024239/scientists-found-rust-on-the-moon
# IDE
Posté par Loïc Blot (site web personnel) . Évalué à 7.
La question que je me pose et qu'on n'aborde pas ici, c'est quel IDE utiliser pour Rust ?
Il n'y en a pas beaucoup, j'ai testé VS Code, vim avec les plugins de rust langageserver mais cela reste un peu trop bricolage pour faire du développement Rust robuste. En avez vous des préférentiels pour débuter ?
Veepee & UNIX-Experience
[^] # Re: IDE
Posté par xcomcmdr . Évalué à 4.
De ce que j'ai vu, VSCode reste le mieux, avec l'extension officielle. Le débogage fonctionne, aussi.
C'est là dessus que se concentrent les efforts de la communauté si j'ai bien compris.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: IDE
Posté par claudex . Évalué à 4.
Ah, je ne suis pas arrivé à le faire fonctionner. Je mettais un breakpoint et il ne s'arrêtait jamais.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: IDE
Posté par xcomcmdr . Évalué à 2.
L'extension C/C++, NativeDebug, voire CodeLLDB font l'affait.
Exemple :
https://jason-williams.co.uk/debugging-rust-in-vscode
Ou l'ancienne manière :
https://www.forrestthewoods.com/blog/how-to-debug-rust-with-visual-studio-code/
Dans tous les cas il faut gdb ou un autre débogueur.
Perso ça marchait bien avec l'extension C/C++ et le débogueur de la suite MSVC.
Mais NativeDebug / CodeLLDB avaient l'air d'être plus modernes.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: IDE
Posté par Sylvestre Ledru (site web personnel) . Évalué à 3.
https://github.com/rust-analyzer/rust-analyzer / https://marketplace.visualstudio.com/items?itemName=matklad.rust-analyzer en tant qu'extension pour code est excellent!
[^] # Re: IDE
Posté par Letho . Évalué à 1.
Je plussoie, rust-analyzer est vraiment excellent, et le plugin officiel devrait d'ailleurs également basculer sur ce dernier à court terme.
[^] # Re: IDE
Posté par Tpt . Évalué à 1.
Il y a aussi un plugin Rust pour la suite d'IDE dérivé d'IntelliJ. Il fonctionne très bien avec l'open source IntelliJ IDEA sauf de débugger qui nécessite une licence de l'IDE propriétaire CLion.
Le plugin fait la coloration syntaxique, l'auto-complétion, le type checking, le "go to definition/find usages", la doc en infobulle, les tests intégrés dans l'UI de tests d'IntelliJ…
# Le "Book" dans la langue de Moliere
Posté par fjbles . Évalué à 10. Dernière modification le 04 septembre 2020 à 12:23.
Certains concepts étant un peu durs a appréhender, ça passe parfois mieux en Français.
Une traduction du "Book" existe:
Le projet github
Le livre
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.