Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

« Rust est le futur de la programmation système et C le nouvel assembleur », d'après un ingénieur d'Intel
Qui explique pourquoi il est pertinent de passer à Rust

Le , par Patrick Ruiz

356PARTAGES

38  0 
Ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. sont dans la filière de la programmation système. Ici, on est dans les méandres du fonctionnement des systèmes informatiques ; on parle de code avec lequel l’utilisateur n’interagit, car distinct de celui de la couche dite applicative.

Le développement du système UNIX a débuté en 1969 et son code a fait l’objet de réécriture en langage C en 1972. En 1985, c’était la sortie de Windows 1.0. Même si le code source du système d’exploitation de la firme de Redmond est fermé, l’entreprise elle-même a indiqué que le noyau du système d’exploitation est principalement écrit en C. C’est pareil pour Linux dont la plus grosse part de la base de code est écrite en C. Mais le langage C ne se limite pas aux projets qui ont débuté il y a des dizaines d’années, ce, lorsqu’il n’y avait pas encore toute la panoplie de langages de programmation qu’on connaît. En fait, en matière de programmation système, le langage C peut désormais être considéré comme l’actuelle norme. « Le langage C est le nouvel assembleur », déclare Josh Triplett d’Intel.

Ce qu’il faut dire c’est que le C s’est imposé aux travailleurs de la filière programmation système pour plusieurs raisons. Lors du récent Open Source Technology Summit, l’ingénieur d’Intel est revenu sur certaines. Primo, il y a qu’en tant que langage évolué, le C permet aux développeurs de gagner en matière d’utilisabilité et de productivité ; c’est moins de lignes du code pour accomplir les mêmes tâches en comparaison à l’assembleur. C’est aussi un niveau de performance qui proche de celui de l’assembleur Deuxio, il y a que le passage au C n’induit pas de pertes en termes de possibilités que l’assembleur offre.


Il y a seulement que lors du dernier Linux Security Summit, des chercheurs en sécurité ont, à côté d’autres, mis le doigt sur l’une des plus grosses tares que le langage C traîne : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon. Lors de sa sortie à l’Open Source Technology Summit, l’ingénieur d’Intel est revenu sur ce détail en ajoutant que « les développeurs ont besoin d’un langage évolué qui apporte réponse aux problèmes qui ne peuvent être résolus en C et qui introduit des fonctionnalités intéressantes. »

Ceux qui programment en langage C savent que le développeur s’occupe à la main des aspects de gestion de la mémoire ; il fait le nécessaire au sein du code pour que réserver des portions de mémoire et les libérer lorsque nécessaire. Ce détail divise les observateurs quant à savoir si l’on doit laisser la main au développeur ou s’appuyer sur des fonctionnalités du langage pour automatiser la gestion de la mémoire. En tout cas, Josh Triplett cite la gestion automatique de la mémoire comme l’un des avantages que le langage Rust offre en comparaison au C.

Le développement de l’ingénieur d’Intel laisse également filtrer que le Rust offre plus d’avantages que le langage C pour ce qui est de l’utilisabilité et de la productivité. « Tout langage qui veut être meilleur que C doit offrir bien plus qu'une simple protection contre les dépassements de mémoire tampon s'il veut se positionner comme une alternative convaincante. Les gens se soucient plus de l'utilisabilité et de la productivité. Ils sont plus intéressés par la possibilité d'accomplir d'importantes tâches avec peu de lignes de code. Il y a aussi que convivialité et productivité vont de pair avec la sécurité. Moins vous avez besoin d'écrire de code pour accomplir quelque chose, moins vous avez de chance d'introduire des bogues de sécurité ou autres », explique-t-il. Ce serait l’une des raisons qui a intéressé Mozilla et a amené la Fondation à arrimer le projet de navigateur Quantum à Rust. Les retours d’expérience font état d’un impact positif sur la réduction du nombre de lignes de code et des failles de sécurité dues à la gestion de la mémoire.

Josh Triplett reconnaît néanmoins que sur le terrain de la parité en termes de possibilités offertes, il y a encore un gap à combler avec le langage C. C’est la raison pour laquelle il a, en 2015, introduit un Request For Comment pour le support natif des unions compatibles C en Rust. L’ingénieur d’Intel a également eu à contribuer pour la prise en charge des structures et des unions sans nom sous Rust. La programmation système implique d’effectuer des manipulations de bas niveau en assembleur. En Rust, l’on s’appuie sur la macro asm, mais à date, elle n’est présente que dans le compilateur en nightly et n’est pas encore stable. En collaboration avec d’autres développeurs Rust, l’ingénieur d’Intel travaille à la mise sur pied d’une syntaxe plus robuste d’introduction de code assembleur au Rust. Plusieurs processeurs s’appuient désormais sur le Brain Floating-Point Format (bfloatf16) – un format de données dont on fait usage en apprentissage profond. À date, le Rust ne dispose pas de support pour ce dernier ; un autre axe sur lequel Triplett est engagé.


Tous ces aspects feront l’objet de développement au sein d’un groupe dont il a annoncé la création. En collaboration avec la communauté Rust et d’autres développeurs chez Intel, l’initiative vise à développer les spécifications pour les fonctionnalités qui manquent pour faire du Rust le langage qui devrait envoyer le C aux oubliettes.

Source : Vidéo

Et vous ?

Qu’en pensez-vous ?

Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?

Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?

Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ?

Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

Voir aussi :

Programmation : un « Pony » peut cacher un langage, l'outil adéquat, d'avis d'utilisateurs, pour le développement d'applications concurrentes

C2 : un langage qui se présente comme une évolution de C, plus rapide, sans fichiers d'en-tête, avec système de build intégré et d'autres changements

Quel avenir pour le langage C ? Un développeur expérimenté fait ses adieux au langage et livre ses inquiétudes quant à son avenir

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 02/09/2019 à 10:27
Citation Envoyé par Patrick Ruiz Voir le message
le langage C peut désormais être considéré comme l’actuelle norme. « Le langage C est le nouvel assembleur », déclare Josh Triplett d’Intel.
Attention Josh Triplett a bien expliqué que cette phrase n'avait pas pour vocation a servir de titre. C'est une personne qui a écrit un rapport sur la présentation qui l'a utilisé ainsi. Josh Triplett a bien précisé qu'il n'aurait pas choisi ce terme car sa présentation se voulait nuancé et pas en opposition frontale au C.

Citation Envoyé par Patrick Ruiz Voir le message
Ceux qui programment en langage C savent que le développeur s’occupe à la main des aspects de gestion de la mémoire ; il fait le nécessaire au sein du code pour que réserver des portions de mémoire et les libérer lorsque nécessaire. Ce détail divise les observateurs quant à savoir si l’on doit laisser la main au développeur ou s’appuyer sur des fonctionnalités du langage pour automatiser la gestion de la mémoire. En tout cas, Josh Triplett cite la gestion automatique de la mémoire comme l’un des avantages que le langage Rust offre en comparaison au C.
Cette présentation des choses est un peu trompeuse : l'avantage de Rust pour la programmation système par rapport à la plupart des autres langages modernes, c'est justement qu'il n'a pas une gestion automatique de la mémoire. Comme en C il faut savoir quand on alloue la mémoire et de quelle manière. Il a plutôt une assistance à la gestion mémoire qui empêche les mauvaises utilisation.

Citation Envoyé par Patrick Ruiz Voir le message
Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Je pense que oui, les avantages de Rust sur le C sont indéniables. Par contre, comme c'est expliqué dans cette présentation, le C garde des avantages dans certains contexte, en grande partie à cause de sa place centrale actuelle dans la programmation système.
Ça n'est pas demain que Rust va remplacer 100% du code C, mais c'est quelque-chose qui gagnerait clairement à se faire sur la durée.

Citation Envoyé par Patrick Ruiz Voir le message
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
Cette question n'a pas de sens. Bien sur qu'avec des développeurs parfait, ont pourrait tout faire en C, en assembleur, voire directement en langage machine, ...
Dans la pratique un langage adapté permet d'être plus productif et plus fiable.

Citation Envoyé par Patrick Ruiz Voir le message
Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ?
A moyen terme oui, ça semble une bonne idée. C'est le genre de projet ou Rust à toute sa place. A court terme, probablement pas, c'est le genre de transition dans laquelle on ne se lance pas à la légère.

Citation Envoyé par Patrick Ruiz Voir le message
Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?
C'est des cas a étudier au cas par cas, comme expliqué dans la présentation, il reste des cas ou Rust n'est pas encore totalement adapté.
Mais Rust est en effet utilisable, dès aujourd'hui dans la grande majorité des projet de prog système où l'on aurait envisagé que le C ou le C++ il y a quelques années.

Citation Envoyé par Neckara Voir le message
Ouais, enfin des "futurs de la programmation", on en a 10 par ans...
C'est pas faux, mais il faut reconnaitre que Rust a fait bouger les lignes dans la programmation système qui étaient complètement figées depuis des années.
14  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 04/09/2019 à 10:52
Citation Envoyé par CoderInTheDark Voir le message
Au final ça sert à quoi un pointeur en C/C++ ?
Car le fond de l'article c'est quand même la gestion de la mémoire en C, qui est source d'erreur.
En C, un pointeur ça sert a énormément de choses. Tellement que c'est difficile de toutes les citer. Parmi les plus courantes on a : gérer les tableaux, allouer de la mémoire, passer les arguments à une fonction, accéder directement à des périphériques mappés en mémoire,...

Citation Envoyé par CoderInTheDark Voir le message
Pour cette utilisation il vaut mieux avoir un modèle managé comme en Java ou .net ça évite les erreurs.
En effet mais les environnements managés, ça a un coût, notamment en performance et en capacité d'accès au matériel à bas niveau.
Donc le managé n'est pas vraiment utilisable pour la prog purement système comme un BIOS, des drivers matériel ou un OS. Et même pour les applications classiques qui requièrent rapidité et prédictibilité des performances, ça peut être un problème.

Citation Envoyé par CoderInTheDark Voir le message
D'ailleurs c'est quoi les erreurs de programmation de pointeur en C c'est de confondre le * et le & ?
De ne pas initialiser le pointeur ?
Se tromper de type et de faire un débordement ?
D'oublier de libérer la mémoire ?
Il y a plusieurs types d'erreurs mémoire, en général on considère que les erreurs de sécurité mémoire sont :
  • use after free : on utilise une zone mémoire qui a été libérée. Ce qui veux dire que si cette zone est réallouée on aura deux pointeur qui écriront des chose complètement différentes dans la même zone mémoire.
  • double free : on libère une zone mémoire déjà libérée ce qui peut provoquer des problèmes. Par exemple, si la zone avait été réallouée, on la libère par erreur et provoque un use after free.
  • data race : plusieurs threads modifient de manière non synchronisée la même zone mémoire.
  • mémoire non initialisée : donne accès a des valeurs qui devraient pas être accessibles
  • buffer overflow : un pointeur qui pointe a une adresse non allouée, généralement par dépassement de la taille d'un tableau, ce qui lui permet d'accéder et/ou modifier des variables auxquelles il ne devrait pas avoir accès.

Oublier de libérer de la mémoire peut aussi être considéré comme une erreur de gestion de la mémoire, mais il ne s'agit pas d'un problème de sécurité : le programme va juste surconsommer de la mémoire.

Citation Envoyé par CoderInTheDark Voir le message
Rust c'est quoi au final un C sans pointeur ?
Au contraire Rust utilise beaucoup les références (l’équivalent des pointeurs), mais le compilateur n'autorise pas à faire n'importe quoi avec. Dès la compilation il garantit que :
  • Chaque donnée en mémoire a une variable qui en est propriétaire et qui est la seule à pouvoir la libérer. Toute les références à cette donnée doivent être invalidées avant de pouvoir la libérer.
    Cela empêche les "use after free" et "double free".
  • Une donnée peut avoir, soit une seule référence qui permet de la modifier, soit plusieurs référence mais toutes en lecture seule.
    Cela empêche les data-races.
  • Les références (et plus généralement toutes les variables) doivent être initialisées avant toute utilisation.

Pour prévenir les buffer overflow par contre, ça ne peut être fait qu'a l'exécution. Le code généré contrôle que les accès aux tableaux sont dans les limites, sauf si le compilateur peut prouver que le contrôle n'est pas nécessaire, par exemple dans le cas d'un accès au tableau par itérateur.

Pour la libération de la mémoire Rust fournit plusieurs type d'outils pouvant aider (destructeurs, comptage de référence,...) mais il ne garantit pas l'absence de fuite mémoire.
14  0 
Avatar de Jamatronic
Membre éclairé https://www.developpez.com
Le 02/09/2019 à 11:17
Citation Envoyé par Neckara Voir le message


C'est jusque qu'on nous dit sans cesse "il faut abandonner C, il faut passer à Go", "il faut abandonner C, il faut passer à D", "il faut abandonner C, il faut passer à Rust", "il faut abandonner C, il faut passer à Objective C", ...
Tout ceci est plutôt signe qu'il ne vaut mieux pas abandonner C, en fait.
9  1 
Avatar de Neckara
Expert éminent sénior https://www.developpez.com
Le 02/09/2019 à 9:43
Ouais, enfin des "futurs de la programmation", on en a 10 par ans...
10  3 
Avatar de Mimoza
Membre averti https://www.developpez.com
Le 02/09/2019 à 11:44
Je ne sais pas si c'est un avis partagé, mais Go a eu son moment de gloire avec Docker, mais Rust a l'air de convaincre bien plus de monde …
Pour ma part si je devais investir sur un langage Rust me parait un meilleur choix.
Seul l'avenir nous le dira.
7  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 02/09/2019 à 13:58
Citation Envoyé par Neckara Voir le message
C'est jusque qu'on nous dit sans cesse "il faut abandonner C, il faut passer à Go", "il faut abandonner C, il faut passer à D", "il faut abandonner C, il faut passer à Rust", "il faut abandonner C, il faut passer à Objective C", ...
C'est pas du tout l'impression que j'ai, par contre chaque fois que je vois une présentions honnête d'un langage qui ne prétend rien de plus que pouvoir fournir une alternative, je vois des défenseurs du C qui se lamentent comme si on allait exiger de remplacer l'intégralité du code C existant, sous 15 jours, pour les mettre définitivement au chômage.

Je vois pas grand monde de sérieux dans l'industrie qui dit, "il faut abandonner C, il faut passer à X", du moins pas de manière absolue, pas sans une étude du contexte qui indique que le changement est vraiment utile et pas sans un plan de transition bien pensé.

Citation Envoyé par Neckara Voir le message
Je n'ai rien contre un successeur du C, mais tout le monde veut être son successeur, or, on ne pourra pas en avoir 50 successeurs, et on ne va pas changer de langage tous les mois, au gré des modes.
C'est évident qu'on ne va pas changer de langage tous les mois, mais j'ai vraiment l’impression que ce genre de discours sert surtout d'excuse à beaucoup de gens pour ne pas prendre la peine de regarder plus loin que le bout de leur nez, ce qui est quand même fort dommage.

Citation Envoyé par Mimoza Voir le message
Je ne sais pas si c'est un avis partagé, mais Go a eu son moment de gloire avec Docker, mais Rust a l'air de convaincre bien plus de monde …
Pour ma part si je devais investir sur un langage Rust me parait un meilleur choix.
Seul l'avenir nous le dira.
C'est surtout que c'est une très mauvaise approche du problème. Il n' y a pas besoin de chercher un langage vainqueur qui battrait tous les autres. Le problème, c'est "Est-ce que le langage est efficace à remplir sa mission par rapport aux alternatives existantes ?".

Il n'y a pas besoin de trouver un gagnant entre Rust et Go, vu que même si on peut leur trouver des points communs, ils ne recouvrent pas exactement les mêmes besoins. Go n'étant pas du tout un langage système (contrairement a ce qui a été annoncé au début), il n'est pas du tout adapté à faire des application embarquée, temps réel, des drivers, un OS, ... Par contre sa bibliothèque et sa facilité d'utilisation en font un très bon candidat pour un serveur d'applications Web.

Citation Envoyé par Guntha Voir le message
Pour moi, c'est plutôt un signe qu'aucun des créateurs de ces langages n'a compris pourquoi C était encore utilisé.
Je pense qu'il l'ont très bien compris, c'est juste qu'il ne visaient pas ce marché. D, Go, ... visaient plus les développeurs d'application de haut niveau, ils n'ont pas remplacé le C car ils n'ont jamais réellement essayé de le faire.

Citation Envoyé par 23JFK Voir le message
Présenter un langage dont la syntaxe n'est pas encore stabilisée et auquel il manque de fonctions de substitutions comme un successeur du C est ... Odacieux...
La syntaxe de Rust est stabilisée depuis la version 1.0 (2015). Je suis curieux de savoir ce que tu appelle fonctions de substitution.

Citation Envoyé par Neckara Voir le message
Imagine à l'époque, on te dit "Go c'est l'avenir", tu les écoutes et passe du C au Go. Quelques années plus tard, l'effet de mode disparaît, et on te dit "Rust, c'est l'avenir".
Si c'est comme cela que l'on choisit les langages chez toi, en effet, vous allez avoir un problème. On ne choisit pas un langage, "parce que c'est l'avenir", mais parce qu'il va apporter des avantages (rapidité, fiabilité, ...) et on évite tout particulièrement de le changer sur un projet en cours a moins d'avoir excellentes raison de le faire.
7  0 
Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 04/09/2019 à 11:26
Citation Envoyé par Uther  Voir le message
- Il ne peut y avoir qu'une seule référence qui peut modifier une même donnée, toute les autres doivent être en lecture, ce qui empêche les data-races.

La contrainte est plus forte. Avec une référence en lecture et une en écriture, on peut avoir un data race si on essaie de lire une donnée qui est en train d'être modifiée.

En Rust, le code suivant provoque une erreur de compilation :
Code Rust : Sélectionner tout
1
2
3
4
5
6
fn main() { 
    let mut my_string = String::from("Hello, world"); 
    let mutable_ref = &mut my_string; 
    let immutable_ref = &my_string; 
    mutable_ref.push('!'); 
}
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
error[E0502]: cannot borrow `my_string` as immutable because it is also borrowed as mutable 
 --> src/main.rs:4:25 
  | 
3 |     let mutable_ref = &mut my_string; 
  |                       -------------- mutable borrow occurs here 
4 |     let immutable_ref = &my_string; 
  |                         ^^^^^^^^^^ immutable borrow occurs here 
5 |     mutable_ref.push('!'); 
  |     ----------- mutable borrow later used here
Le langage impose qu'il y ait soit une seule référence muable accessible, soit une ou plusieurs références accessibles mais toutes immuables. Dans mon exemple, let immutable_ref = &my_string; empêche d'utiliser par la suite mutable_ref.
7  1 
Avatar de Marco46
Modérateur https://www.developpez.com
Le 03/09/2019 à 10:35
Citation Envoyé par Neckara Voir le message
Certes, mais combien auraient pensé il y a quelques années qu'on puisse exécuté du JS côté serveur ?
Combien auraient pensé utiliser du JS dans de l'embarqué ? ou de l'IoT ?
JavaScript est utilisé par le biais de Node sur toutes ces plateformes parce qu'il y a un besoin massif d'utilisation du réseau pour les applications quelle que soit la plateforme. C'est ça le grand changement de ces dernières années et c'est pour ça quand JavaScript (par le biais de node) grignote partout.

Pour ce qui est de la prog système je vois pas comment JS pourrait s'y insérer les performances sont plusieurs ordres de grandeur en dessous des langages appropriés. L'usage de node c'est le réseau pas le calcul.
5  0 
Avatar de Astraya
Membre expérimenté https://www.developpez.com
Le 03/09/2019 à 11:31

Je ne comprends pas comment une conversation parlant de Rust et C fini sur JS ou Go...
'C' et 'Rust' sont des languages de programmation Système, JS et Go non.
'C++' dans la moindre mesure je le considère également comme un langage de programmation système.

Ce que sont 'C' et 'C++'

'C' est un vieux language qui a fait ces preuves et qui à également montré qu'il avait de grosses faiblesses qui coute et ont couté plusieurs millions de dollars aux sociétés. ( Use after free, buffer overflow, null pointer, etc... )
'C' à une ABI stable.
'C++' a ajouté 1 élément majeur par rapport au 'C' qui est le destructeur et qui a permit de limiter la casse en libération mémoire, mécanisme 'automatisé' de gestion de mémoire.
'C++' a également apporté l'Orienté Objet (POO) qui aujourd'hui montre également ces faibles après avoir montré sa force.
'C' et 'C++' n'ont pas été pensé pour les problèmes d'aujourd'hui ( Processeurs multicoeurs, Sécurité, Ecosystème du développeur )
'C' et 'C++' ont aux moins 3 compilateurs différents!!! ( GCC, Clang, MSVC)

Ce qu'est 'Rust'

'Rust' prend le meilleur et fait une bonne cuisine de tout ça. (D'ou son nom qui veux dire 'Rouille' car l'ensemble des concepts qu'il met en oeuvre sont des concepts qui ont fait leurs preuves)
- Il autorise l'utilisation de raw pointer, d'allocation dynamique, d'alignement mémoire custom, de 'destructeur' via le trait 'Drop'.
- Son système de Ownership et Borrowing est très bien pensé. Difficile à prendre en main mais d'une puissance indiscutable.
- Il est orienté Data Oriented Design afin de répondre au problème d'aujourd'hui (Multiplication du nom de coeur par exemple) qui demande du code cache friendly (Data et Instruction).
- Il est également orienté Test Driven ( Les tests unitaires et globaux sont parties complètes du language et du compilateur! )
- Il n'autorise pas des pointeurs null dans le 'Rust' ( Dans le 'Rust' unsafe oui ) car le pointeur null est tout simplement une erreur de conception que l'on traine depuis plusieurs décenies Null References: The Billion Dollar Mistake
- Il détecte à la compilation les dépassements mémoires, les use after free, les races conditions...
- Il est basé sur LLVM ce qui lui permet de cibler ce que cible LLVM et également d'utiliser les outils de LLVM et de profiter des optimisations que celui-ci procurent.
- Il n'a pas de garbage collector.
- Il dispose d'un gestionnaire de paquage qui nous rappelle de l'éco-système du 'C' et 'C++' est une catastrophe.
- Il n'y a que 1 seul compilateur rustc!

J'ai lu beaucoup de bétise ici.
'Rust' est stable! Son 'ABI' ne l'ai pas mais pour info C++ non plus.
'Rust' se bind avec 'C' nativement car les OS actuels sont en 'C', ne pas le faire reviendrait à une mort prématuré du language et dire que se n'est pas prétentieux car il bind 'C' montre une incompréhension totale de la réalité.
Est-ce que tous les languages qui se bind avec 'C' sont je cite "pas assez prétentieux pour essayer de s'en passer complètement"? WTF?
Pour 'JS' NPM utilise 'Rust' et pas 'JS'... donc...

'Rust' est actuellement utilisé par et pour

- Mozilla : Moteur de rendu CSS, Firefox et autres....
- Amazon : Outils de builds
- Google : Projet "Fuchsia" de Google
- NPM : "Replacing C and rewriting performance-critical bottlenecks in the registry service architecture."
- Atlassian : "We use Rust in a service for analyzing petabytes of source code."
- Dropbox : https://www.wired.com/2016/03/epic-s...-cloud-empire/
- Microsoft : Azure IoT Edge
- RedHat : Système de sockage de fichier Stratis
- Reddit : Processus de commentaire
- Twitter, Electronic Arts, Unity, OVH, etc...

Liste complète ici
5  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 03/09/2019 à 12:30
Citation Envoyé par Astraya Voir le message
Jai? Google ne trouve rien.
Jai est un langage de programmation créé par Jonathan Blow (auteur des jeux-videos Braid et The Witness), qui estimait que la plupart des nouveaux langages ne sont pas adaptés au jeu-video. En gros il veut quelque-chose de plus moderne que le C mais sans les contraintes liées à la sécurité de Rust comme le borrow checker qu'il n'estime pas rentable pour le jeu video. Pour lui le principal est un langage qui compile vite et facile a déboguer.

Et si tu as du mal a trouver sur Google, c'est normal vu que le langage n'est pour le moment pas distribué publiquement. Jonathan Blow a juste fait quelques présentations video de celui ci que tu dois pouvoir trouver sur YouTube. Le langage n'est actuellement utilisé qu'en interne pour les jeux de Jonathan Blow et il semble plutôt instable : Jonathan Blow a encore annoncé récemment qu'il a modifié des concepts clé du langage.
5  0