Discussion :

[Uther]

Je n'ai fait que lire l'article : insert ASM , union/structure.

Ok, tu parles des fonctionnalités expérimentales qui ne sont pas encore disponible dans la version stable du compilateur. C'est vrai qu'il y en a un certain nombre.
Mais le langage en lui même est stable : le code compilé avec une version stable du compilateur et garanti de continuer à compiler avec les version à venir du compilateur.

Ça n'a rien de différent du C : lui aussi a ajouté des nouveautés au langage au fur a mesure de son évolution. D'ailleurs sur le problème de l'assembleur inline, le C est même pire que Rust : cette fonctionnalité ne fait pas partie du standard C et chaque compilateur C a sa propre syntaxe.

[forthx]

Je vais esquiver la discutions JS vs C c'est dangereux

Pour le rust vs C, ma position et d'attendre de voir.

Passer sur un nouveau langage c'est une nouvelle syntaxe/grammaire mais aussi de nouveaux paradigmes et souvent une nouvelle API , même élémentaire.
Je passe sur les lib que l'on a l'habitude d'utiliser et le code historique mais ca représente évidemment un problème.
En tant qu'utilisateur je serais plus convaincu par une évolution du C qui permette une gestion de la mémoire plus simple et plus sur.
Mais j'imagine que ca ne doit pas être facile, ca restera sans doute un doux rêve dans ma tête.

Concrètement un peut de rust dans le futur, c'est plausible. C le nouvel assembleur oui et non, que va devenir l'asm dans ce cas ?
Vous ne voudriez pas condamner un langage d'une telle simplicité sur l'hotel de l'abstraction tout de même !

[Guntha]

À mon avis, ce qui rend Rust moderne par rapport au C, ce n'est pas seulement sa gestion de la mémoire, mais surtout le fait qu'il ait été pensé dès le départ pour le multi-threading.

Je n'ai fait que lire l'article : insert ASM , union/structure.

D'accord avec Uther là-dessus: c'est comme dire que la syntaxe du C++ est instable parce que toutes les modifications du C++20 n'ont pas encore été décidées

c'est vrai que la gestion mémoire est la 1ere source de bug critique en c et c++. mais j'aimerais bien passer a rust, pourquoi pas. mais 99.9% des lib utiles sont en c ou c++

Rust permet nativement d'appeler des fonctions C : https://doc.rust-lang.org/book/ch19-...-external-code
Rust prétend rivaliser avec le C mais n'est pas assez prétentieux pour essayer de s'en passer complètement.

[nhugodot]

Avant, on devait tout faire avec C/C++. Choix facile, mais développements difficiles.
Maintenant on a 10 ou 30 choix de langages, C/C++ toujours, Rust, Go, Java, Scala, Clojure, Erlang/Elixir pour les rapides, JS python PHP etc pour les apps. Choix difficile, développement facile.
Je préfère maintenant. Développer excel ou un webmail en C++, non merci.

Pire, on est au cloud donc parallélisation : adieu C/C++, merci les Golang et les FP ! Pas pour rien que Google, roi du cloud, avait besoin d'un golang. Et whatsapp d'un erlang.

Bref , ça n'a rien d'une mode mais d'un besoin réel, une réponse à un vrai blocage. On n'a pas remplacé le cheval par un seul moyen de locomotion non plus... "un peu de tout, beaucoup de rien".

Par contre, Julia, avec ses bindings a tant d'autres langages, est séduisant... V1 aujourd'hui, on verra dans 10 ans ou il sera. Bravo aux concepteur !
A quand ces vrais langages propres sur ASM...

[Invité]

Il s'est quand même bien étendu depuis sa création, de côté client, il a gagné côté serveur, et peut même être utilisé pour des applications desktop.

La programmation web et la programmation d'appli desktop, ce n'est pas de la programmation système.
Si tu regardes les 20 premières secondes de la vidéo de l'article, il y a des exemples de prog système : bios, firmware, bootloaders, OS, etc
Perso je connais pas beaucoup de bios codé en JS...

[Neckara]

La programmation web et la programmation d'appli desktop, ce n'est pas de la programmation système.

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 ?

Pour le moment, JS suit le chemin : navigateur -> serveur -> IoT -> Embarqué. Combien de temps avant qu'il ne s'attaque aussi à la programmation système ?


J'en suis le premier attristé, mais le constat est là.

[Invité]

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 ?

Pour le moment, JS suit le chemin : navigateur -> serveur -> IoT -> Embarqué. Combien de temps avant qu'il ne s'attaque aussi à la programmation système ?

Formidable, il existe deux bibliothèques JS pour l'IOT et l'embarqué... Quel raz-de-marée... Et qui les utilisent vraiment ? Avec quel succès ?

Autant dire que Rust est en train de supplanter JS parce qu'on peut charger des modules rust dans nodejs ou du webassembly dans une page web.

[Neckara]

Formidable, il existe deux bibliothèques JS pour l'IOT et l'embarqué... Quel raz-de-marée... Et qui les utilisent vraiment ? Avec quel succès ?

C'est bien facile d'ironiser.

Voici ce que je trouve après une rapide recherche Google:

1. Java
2. C
3. JavaScript
   
4. Python

http://www.reseaux-telecoms.net/actu...iot-27697.html

Capteurs et objet connectés dits contraints >
1. C
2. C++
3. Java
4. JavaScript

Passerelles de l’IoT >
1. Java
2. Python
3. C++
4. C

Cloud IoT >
1. Java
2. JavaScript
3. Python
4. PHP

Il ne faut pas être un génie pour comprendre que si on utilise de plus en plus JS côté serveur, on a de forte chance de le retrouver dans l'IoT, ou nombre d'interfaces de gestion sont des serveurs Web.

[youtpout978]

Je vois beaucoup d'articles qui vont dans le même sens pour Rust, en tout cas c'est un langage qui me tente à l'avenir je fais pas de système ou du C mais ça serait un bon moyen de mettre le pied dedans et en même temps un pari sur l'avenir

[Marco46]

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.

[wallas00]

J'ai du mal à comprendre certains développeurs.

Vous avez de " l'expérience " en programmation et en management de projet logiciel; allez donc tester le langage et faites-vous votre propre opinion.

Evidemment, le C conserve sa place car il est compliqué voir impossible de migrer vers du pur RUST immédiatement(go and see "are we yet"). Sans oublier que:
- l'intégration de l'assembleur au RUST est encore instable.
- l'utilisation de code unsafe nécessite une gymnastique dont certains développeurs d'OS se passeraient bien.

En outre, j'ai testé RUST et GO; ma conclusion:

Il n'y a pas photo. RUST est LE langage de programmation système MODERNE. Ce n'est pas juste un langage de programmation, c'est un d'environnement qui offre une ergonomie, ou devrais-je dire, une "expérience utilisateur(développeur)" qui respecte les critères " qu'on adore en 2019" chez les devs. Je parle évidement:
- d'une installation et une gestion des versions bien faite.
- du support(librairies) des tests intégré au coeur du langage.
- un compilateur vachement stylé; avec des messages clairs.

- de son package manager qui va fera bientôt rougir npm.
- d'une communauté extrêmement active. Allez check le thread reddit du langage.
- bref la productivité est ou sera certainement au rendez-vous... que du bonheur.

Personnellement, lorsque je veux critiquer "sauvagement" le JAVA et son environnement (dont j'ai conscience de l'évolution permanente, mais reste insatisfait), je prend l'exemple de RUST.

[Astraya]

---

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

[Neckara]

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.

Pas que, c'est aussi l'aspect langage unique qui a permis à JS de gagner du terrain.

D'avoir le même langage côté client et côté serveur, nécessitant moins de compétence (pas besoin d'apprendre PHP), et aussi de réutiliser du code.

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.

Quand ton IoT utilise node pour son interface serveur, tu as de fortes chances de vouloir utiliser le même langage pour le reste de ton IoT, d'où le fait de retrouver un peu de JS en embarqué.

Même s'il est vrai que C, C++, ou l'assembleur fournissent de meilleures performances, il n'est pas dit qu'un jour on retrouve du JS compilé en byte-code, à la manière du Java et d'avoir des "JavaScript processor".
Faut croire que je suis trop en avance sur mon temps.

[Guntha]

Je ne suis pas d'accord avec les derniers commentaires: pour moi, cargo est la plus grosse faiblesse de Rust.
Pour un langage avec une bonne approche de la build, j'attends Jai (ie: le process de build fait partie du code).

[Uther]

Heu... tu as déjà fait des manipulations de bits en JS ? .

Justement "dans son domaine" (sous-entendu le web je suppose) on ne fait pas énormément de manipulation de bit.

Au niveau des bêtises du JS, tu peux en trouver des pages et des pages.

Je suis entièrement d'accord que le Javascript est un langage bancal, mais pour un défenseur du C avec ses presque 200 "undefined behavior", c'est un peu l’hôpital qui se moque de la charité.

Tout du moins, c'est l'impression que j'ai ici en suivant les actualités.

Il y a une grosse différence entre les annonce sur les sites d'actualité qui cherche forcément un peu le sensationnel et ce qui se passe dans les équipes de dev. On ne choisit pas un langage uniquement parce qu'on a vu un joli article mais parce que l'on a pesé les impact positif comme négatif que son utilisation.

Le problème, c'est que tu vas faire un choix à un instant T, mais ce choix, il faudra l'assumer sur une durée qui peut s'étendre à plusieurs années. C'est à dire que l'avenir du langage est très important dans le choix qu'on va faire.

Clairement, la complexité de maintenance et la durée de vie des technologies, fait partie des élément à prendre en compte dans le choix d'un langage, mais leur importance peut varier en fonction des projets.

Je ne me jetterais pas, pour le moment sur le Zig ou le C2 dont l'avenir parait très incertain, sauf pour des projets type R&D dont je sais qu'ils auront une courte durée de vie et très peu d'intervenants.
Par contre quand on voit l’investissement actuel dans le Rust ou le Go, je pense que ces langages peuvent raisonnablement être considérés viables.

En tant qu'utilisateur je serais plus convaincu par une évolution du C qui permette une gestion de la mémoire plus simple et plus sur.
Mais j'imagine que ca ne doit pas être facile, ca restera sans doute un doux rêve dans ma tête.

Beaucoup ont essayé, mais au final se sont rendu compte que c'est impossible de corriger les principaux défauts du C sans en faire un langage fondamentalement incompatible donc de fait un nouveau langage.
Même le C++ core guideline qui devaient établir un sous-ensemble et des pratique d'usage sures du C++ ont revus leur ambition à la baisse et ne prétendent plus garantir la sécurité mémoire.

[Astraya]

Je ne suis pas d'accord avec les derniers commentaires: pour moi, cargo est la plus grosse faiblesse de Rust.
Pour un langage avec une bonne approche de la build, j'attends Jai (ie: le process de build fait partie du code).

Jai? Google ne trouve rien.
En quoi Cargo est une faiblesse? Peux-tu argumenter un peu plus avec ton expérience? c'est toujours interessant.
Cargo n'est pas un compilateur, le compilateur est rustc.
Je vois les autres outils qui "concurrence" Cargo comme des bêtes mortes.
De mon expérience les outils de builds C et C++ sont tellements nombreux que cela en devient ridicule.
En C++ il y a tellement d'outils qui sont nés en urlant qu'il était le futur que au final aucun n'est parfait...
Rust à l'avantage de fournir un outil unique, qui évoluera avec le language.
Pour rappelle c'est un language jeune et dire que Cargo est une faiblesse c'est l'équivalent de tuer le bébé parce que il ne sait pas marcher parfaitement en sortant du ventre de sa mère...

[Uther]

- Il détecte à la compilation les dépassements mémoires, les use after free, les races conditions...
[...]
- Il n'y a que 1 seul compilateur rustc!

Ta présentation de Rust est très bonne, je me permet juste de rectifier ces deux points :

- Les dépassement mémoire sont contrôles à l'exécution (sauf si le compilateur peut détecter que le contrôle n'est pas necessaire), c'est malheureusement techniquement impossible de faire ça à la compilation.
Par contre, en effet, tous les autres type d'erreur mémoire sont rendus impossible dès la compilation.

- En fait il y a bien au moins un compilateur Rust alternatif : mrustc. Il n'a pas le même niveau de finition que rustc (il est pour le moment limité à la version 1.19 et n'a pas de borrow checker). Il possède néanmoins l'avantage de générer du C, ce qui peut être utile pour les plateformes qui n'ont pas de compilateur Rust.

[viper1094]

En C++ il y a tellement d'outils qui sont nés en urlant qu'il était le futur que au final aucun n'est parfait...
Rust à l'avantage de fournir un outil unique, qui évoluera avec le language.
Pour rappelle c'est un language jeune

Ca semble un peu contradictoire. Je veux dire, je ne serais pas étonné que dans 2/3 ans certains trouvent cargo pas assez bon ci ou là, créer une alternative et qu'elles deviennent apprécier de la communauté. Et rebelote 2 ans plus tard. Tu le dis toi même Rust est encore jeune ^^.
Par contre je plussoie totalement le fait que Cargo est l'un des plus gros points positifs de Rust. Sinon autre chose de sympa, comme tu as dis plus haut également, c'est la communauté, ultra active.
Et pour finir, j'voudrais ajouter un dernier truc qui est excellent : le Rust Book. Ca m'étonne qu'on en ai pas parler, mais c'est l'un des cours les mieux fait que j'ai eu l'occasion de lire. C'est aussi un gros point positif pour les débutants dans le langage.

EDIT : Uther, juste au dessus de moi, cite mrust que je ne connaissais pas. Ca ne fait que valider mon point, concernant le fait que la communauté va evidemment sortir des alternatives, pour le bon comme pour le mauvais

[Uther]

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.

[Neckara]

Justement "dans son domaine" (sous-entendu le web je suppose) on ne fait pas énormément de manipulation de bit.

Dès que tu fais un peu de crypto, tu en fais sans le savoir, car tu utilises des bibliothèques.

Cela dépend aussi de ce que tu implémentes, par exemple sur des systèmes d'authentification multi-facteurs biometriques, des jeux en lignes HTML5, démonstrations en lignes, ... tu peux être amené à manipuler des bits.
Ce n'est pas parce que tu utilises rarement cette fonctionnalités, que de telles problèmes de langages en sont acceptables pour autant.


Et si on n'en fait pas, c'est peut-être aussi parce que c'est complètement pêté, et qu'on évite de trop y toucher quand on peut l'éviter.

Je suis entièrement d'accord que le Javascript est un langage bancal, mais pour un défenseur du C avec ses presque 200 "undefined behavior", c'est un peu l’hôpital qui se moque de la charité.

Sauf que la différence est que ces "undefined behavior" sont des choses à ne pas utiliser (généralement erreur de programmation), et sont défini tels quels.
Pour rappel, le C vise la performances, et donc n'a pas pour objectif de vérifier que tu ne fais rien de "mal".

Alors qu'en JavaScript, cela fait parti intégrante des fonctionnalités du langage... C'est une erreur de conception/spécification du langage...

Il y a une grosse différence entre les annonce sur les sites d'actualité qui cherche forcément un peu le sensationnel et ce qui se passe dans les équipes de dev. On ne choisit pas un langage uniquement parce qu'on a vu un joli article mais parce que l'on a pesé les impact positif comme négatif que son utilisation.

Ce qui se passe dans les équipes de devs ne sont pas l'objet de ma critique.
Pour rappel, je critiquais le fait qu'on nous annonce 10 successeurs du C par ans.

Par contre quand on voit l’investissement actuel dans le Rust ou le Go, je pense que ces langages peuvent raisonnablement être considérés viables.

Le problème, c'est qu'on ne sait jamais de quoi l'avenir sera fait. Est-ce qu'un autre langage va les supplanter et siphonner leurs communauté ?