Discussion :

[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 !

[23JFK]

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...

[Aiekick]

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++

[Uther]

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++

A part au niveau des GUI, L'écosystème de bibliothèque Rust commence quand même à être pas mal fourni, et on peut s'interfacer sans trop de difficulté aux bibliothèques C, et avec un peu plus de travail aux bibliothèque C++.

En fait, il existe un sous-ensemble du langage D qui cherche explicitement à remplacer le C. Il est généralement nommé DasBetterC ou BetterC. Avec un compilateur D, cela correspond à l'option -betterC. Cela interdit plusieurs fonctionnalités disponibles en D normal, dont le ramasse-miettes et les exceptions.
Mais ça m'étonnerait que DasBetterC réussisse à s'imposer face à Rust.

En effet j'en ai entendu parler, cela dit il me semble que c'est quelque chose qui était difficilement utilisable jusqu'à recement, le D n’avait pas vraiment cet objectif à la base.

[JPLAROCHE]

je ne veux pas polémiqué mais des solutions dans GCC pour c/c++ comme "-ftree-coalesce-vars -fstack-clash-protection -fstack-protector-all" et d'autre encore peuvent juguler les fuites.

[Uther]

Il y a des solutions palliatives en C et C++ pour limiter la casse, mais c'est très loin de couvrir tout ce que fait Rust en matière de sécurité.

[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...

[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

[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.

[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).

[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...

[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.

[Guntha]

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.

https://github.com/BSVino/JaiPrimer/...code-execution
Le doc est un peu vieux (2017) et le langage n'est même pas encore en bêta privée (il est utilisé par 1 seule équipe pour l'instant), mais les concepts sont là. Rien n'empêche d'implémenter un cargo dans le code qui sera exécuté à la compilation .

C'est surtout la façon dont le Rust Book en parlait qui me gênait ("Dès qu'un projet devient un peu gros, vous ne pouvez pas vous passer de cargo"), mais en pratique rien n'empêche de passer directement par rustc et de gérer ses libs différemment (ne serait-ce que pour pouvoir builder un projet sans connexion internet si besoin...).

Je suis d'accord que les systèmes de build existants en C/C++, c'est n'importe quoi, et de mon expérience ils compliquent plus la vie qu'autre chose.

Pour rappel, je critiquais le fait qu'on nous annonce 10 successeurs du C par ans.

Je dis peut-être une bêtise, je ne me rappelle pas de toutes les annonces de remplaçants du C, mais quand c'est un ingénieur d'Intel qui le dit, on l'écoute un peu plus que les autres (La programmation système, c'est un peu leur fond de commerce...)

[deedub]

La question n'est pas juste est-ce que Rust peut remplacer le C, mais est-ce que C est le langage adapté à ce qu'on fait avec ? Pourquoi faire en C des applis où la sécurité est critique ? Ou alors des applis avec des interfaces graphiques gourmandes avec des allocations complexes de mémoire et donc de gros risques de memory leaks ?

[VBurel]

...permettant de faire des sources code cross-plateforme... et aujourd'hui c'est très utile!

Je suis en fait surpris de lire:

"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"

On se dit que le dernier "Linux Security Summit" a eu lieu dans les années 80 alors ? Non parce que tout programmeur 'C' a sa librairie de gestion mémoire contrôlée / checkée / managée... Comment peut on parler de la découverte d'une "tare du langage 'C'" ? Le 'C' c'est la liberté, donc on peut faire tout ce qu'on veut, y compris des outils pour fiabiliser la gestion mémoire...

Je rappelle que dès les années 90, y'avait même des outils additionnels au compiler (genre boundchecker) pour surcharger les fonctions système et Controller la gestion mémoire et autres... https://en.wikipedia.org/wiki/BoundsChecker

Et à propos de productivité, il me semble qu'en programmation elle est fonction de la taille de sa boite à outils et de l'expérience qu'on en a (pas vraiment du langage donc).

Aucun langage n'a remplacé le 'C' en 47 ans, et c'est pas dans la prochaine décennie que ca arrivera... Rendez vous en 2030!

[Uther]

Tu ne vois rien d'incohérent quand ton bit de signe se balance n'importe comment ?

Un exemple tout bête:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
1>>32 // 1
1>>31>>1 // 0

Marrant, je ne m'étais jamais posé la question de décaler de plus que la taille du nombre d'origine, vu que c'est le genre d'opération dont l'utilité parait discutable.

Mais après vérification, quasiment tous les langages fonctionnent ainsi (y compris les compilateurs C que j'ai essayé, je n'ai pas le courage de vérifier si c'est un UD). Quand on décale un nombre de N bits de X bits vers la droite, on décale en fait de X modulo N. Si tu essaie en C avec un int32_t, tu devrais avoir le même comportement.

Franchement, si tu codes bien et proprement, les UB de C ne posent aucun problèmes.

Cette affirmation me parait douteuse quand on sait que 70% des failles de sécurités de Microsoft dans les applications les plus surveillées au niveau de la qualité du développement viennent des UB liés à la mémoire (ils n'ont pas donné de chiffre pour les autres UB).
Je ne met pas en doute ta sincérité, mais le ressenti personnel, c'est pas vraiment fiable. Personnellement, un développeur C qui dit qu'il n'a aucun problème avec les UB, ça m'inquiète plutôt que ça ne me rassure.

...permettant de faire des sources code cross-plateforme... et aujourd'hui c'est très utile!

C'était probablement le moins mauvais du domaine dans les années 70, mais au niveau du code source, le C n'est absolument plus le meilleur langage pour la portabilité. Alors certes c'est faisable de faire du code C portable mais c'est beaucoup plus compliqué que dans la plupart des langages modernes.

Par contre au niveau du support des architectures, il est vrai que le C est le seul langage a avoir un compilateur pour tout et n'importe quoi, y compris les microcontrôleurs les plus obscurs.

Je suis en fait surpris de lire:

"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"

On se dit que le dernier "Linux Security Summit" a eu lieu dans les années 80 alors ?

Je pense que tu as mal interprété la phase de l'article qui, il est vrai, peut porter à confusion. Le problème de la sécurité du C n'est pas nouveau, mais il fait partie des points qui ont été spécifiquement abordé lors de cette conférence notamment lors de la présentation de Josh Triplett.

Non parce que tout programmeur 'C' a sa librairie de gestion mémoire contrôlée / checkée / managée... Comment peut on parler de la découverte d'une "tare du langage 'C'" ? Le 'C' c'est la liberté, donc on peut faire tout ce qu'on veut, y compris des outils pour fiabiliser la gestion mémoire...

Il existe certes des outils variés pour limiter les risques, qui apportent leur propre complexité et parfois de nouveaux risques s'ils sont mal utilisés, mais aucun n'apporte un niveau de garantie comparable à ce que permet Rust contre les erreurs mémoire.

[Neckara]

Oui et? Aucun programmeur sérieux n'utilise cet opérateur donc le problème c'est?

S'il ne sert à rien, pourquoi existe-t-il alors ?

Ou plutôt, pourquoi '===' n'a-t-il pas directement remplacé '==' à la conception du langage ?
Sachant que c'est bien '==' qui est utilisé dans tous les autres langages.

Marrant, je ne m'étais jamais posé la question de décaler de plus que la taille du nombre d'origine, vu que c'est le genre d'opération dont l'utilité parait discutable. Mais après vérification, quasiment tous les langages fonctionnent ainsi (y compris les compilateurs C que j'ai essayé, je n'ai pas le courage de vérifier si c'est un UD). Quand tu décales un nombre de N bits vers la X droite tu décale en fait de X modulo N.
Essaie en C avec un int32_t et tu devrais avoir le même comportement.

En effet, mais pour être honnête, cela génère un warning avec gcc.


Mais j'en ai d'autre sous le coude, si tu veux:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
1 << 31 >> 31 // -1
// ce qui te force à utiliser des >>> à longueur de temps.
// e.g. 1 << 31 >>> 0 // pour retirer le bit de signe.

1 << 31 >>> 0 >>> 2 // 536870912
1 << 31 >>> 0 >> 2 >>> 0 // 3758096384

Je ne met pas en doute ta sincérité, mais le ressenti personnel, c'est pas vraiment fiable. Personnellement, un développeur C qui dit qu'il n'a aucun problème avec les UB, ça m'inquiète plutôt que ça ne me rassure.

Personnellement, cela fait des années que je n'ai pas eu de problème avec les UB en C.

[spoiler=Découvrez mon secret]Je suis obligé de coder en JS [\spoiler]

Après, comme l'ont dit d'autres intervenant, tu peux utiliser des libs pour faire des vérifications.
Pour être honnête, je suis un peu plus C++ que C.

[Uther]

Mais j'en ai d'autre sous le coude, si tu veux:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
1 << 31 >> 31 // -1
// ce qui te force à utiliser des >>> à longueur de temps.
// e.g. 1 << 31 >>> 0 // pour retirer le bit de signe.

1 << 31 >>> 0 >>> 2 // 536870912
1 << 31 >>> 0 >> 2 >>> 0 // 3758096384

Je vois pas ou est le problème. Le comportement est exactement le même que dans tout les autres langages sur des nombres 32 bits y compris C (sauf bien sur pour l'opérateur >>> qui n'existe pas en C standard).

Autant il y a plein de choses à reprocher à JS, les décalages ne semblent pas un vrai problème pour moi.

[spoiler=Découvrez mon secret]Je suis obligé de coder en JS [\spoiler]