Discussion :

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

[Uther]

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.

Justement 99% des développeur JavaScript ne feront jamais directement de crypo ou de graphisme bas niveau, au pire ils passeront par des bibliothèque.
Le langage n'est en effet pas idéal pour les développeur de la bibliothèques mais c'est une part microscopique des utilisateurs de Javascript qui ne fait clairement pas partie du "domaine" d'utilisation habituel.
D'ailleurs avec WASM elle pourrait même complètement disparaitre.

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

Au final, dans les deux cas, c'est des utilisations qu'il faut éviter. Au moins dans le cas du JavaScript le comportement est consistant.

[viper1094]

ne serait-ce que pour pouvoir builder un projet sans connexion internet si besoin

Sauf erreur de ma part, c'est pas forcément très utile. Si tu as l'occasion de download les crates il suffit de les inclure dans un fichier .rs ne faisant que ça ( au pire tu gardes le hello world aussi ). Les crates seront donc download et ensuite tu pourras bosser offline. Et si tu parlais de download sur un pc X, et d'ensuite inclure la lib dans pc Y avec une clé usb, bah, ça reste quand même un cas d'utilisation ultra particulier.
Puis le cargo.lock est quand même génial au niveau de la gestion des dépendances, surtout quand les versions différe beaucoup.

EDIT : Oh et concernant les GUIs en Rust dont parler Uther, les libs pour ne sont effectivement pas mature, mais il commence a y avoir quelques projets intéressants. Je citerais entre autre Conrod qui est très sympa à utiliser et évidemment tous les bindings de Qt, GTK et compagnie ( plus d'info ici si ça t'interesse). Pour le coup ça semble déjà vraiment pas mal, surtout pour la jeunesse du langage.
Ce qui serait sympa c'est quelque chose dans le genre de Qt en Rust pure, et ça ça manque je te l'accorde ( Conrod étant vraiment pas fait pour des gros projets ( organisation difficile, c'est pas penser pour)).

[Uther]

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

Théoriquement un dépôt/compilateur alternatif est possible, mais le fait d'avoir un dépôt maintenu par l'équipe qui développe le langage et le compilateur original, ça aide quand même a se poser en référence, alors que les multiple initiatives concurrentes faites pour le C/C++, lancées par des gens sans gros poids peinent à fédérer.

[Neckara]

Justement 99% des développeur JavaScript ne feront jamais directement de crypo ou de graphisme bas niveau, au pire ils passeront par des bibliothèque.

Et qu'est-ce que tu fais des 1% restant ?

De surcroît, JS s'étend, et on le retrouve côté serveur, où on pourra avoir des services qui, eux, feront plus de calculs.

D'ailleurs avec WASM elle pourrait même complètement disparaitre.

Tu perds un peu l'intérêt du langage unique dès lors.

Après si WASM pouvait juste faire disparaître JS...

Au final, dans les deux cas, c'est des utilisations qu'il faut éviter. Au moins dans le cas du JavaScript le comportement est consistant.

Quel intérêt que le comportement soit consistant s'il faut l'éviter ?

En revanche, en JS, ces utilisations à éviter sont contre-intuitives, vont à l'encontre de grands principes de programmation, et il faut au moins s'être fait avoir une fois, avoir perdu un après-midi pour cette bêtise, pour le savoir.

[Astraya]

Théoriquement un dépôt/compilateur alternatif est possible, mais le fait d'avoir un dépôt maintenu par l'équipe qui développe le langage et le compilateur original, ça aide quand même a se poser en référence, alors que les multiple initiatives concurrentes faites pour le C/C++, lancées par des gens sans gros poids peinent à fédérer.

Exactement!
Ils fournissent également un RLS pour Rust qui lui permet de s'intégrer à l'EDI de son choix. Pour cela il utilise rustc et rustfmt! Sans un environnement entièrement contrôlé par Rust et Mozilla on arrive à des choses comme C et C++.
Après si un petit génie vient présenter une alternative viable pourquoi pas mais on tomberais alors dans le problème de Linux à savoir la fragmentation de l'environnement!
Personnement, je cherche toujours une solution avec les outils officiels car leurs intégrations est souvent bien meilleur que toutes autres solutions externes.
Et si un jour Cargo vient à être obselete je ne doute pas de Mozilla et la communauté pour remédier au problème.

[viper1094]

Oui tu as raison Uther, j'aurais bien objecté qu'on peut douter de la qualité du maintien futur, mais c'est Mozilla derrière .
Et Neckara, si je peux me permettre, le problème avec Js c'est plus la mentalité du langage unique qu'il entraine, et les apps desktop avec Electron et nw.js.

De surcroît, JS s'étend, et on le retrouve côté serveur, où on pourra avoir des services qui, eux, feront plus de calculs.

Mmh... Dans l'absolu ce qui me ferait peur dans ce cas c'est d'y voir des libs faites en js pour js, parce que de simple bindings d'unlangage performant dans les domaines en questions, c'est pas un si gros problème. Si ?

[Uther]

Et qu'est-ce que tu fais des 1% restant ?

Rien! Aucun langage n'est parfaitement adapté à 100% des cas et puis c'est tout. C'est pour cela qu'il y en a plusieurs.
C ne fait pas exception à la règle.

De surcroît, JS s'étend, et on le retrouve côté serveur, où on pourra avoir des services qui, eux, feront plus de calculs.

Si il y a des gens pour utiliser JavaScript sur serveur, alors que rien ne les y oblige, c'est leur problème. Comme je l'ai dit, il faut faire le choix du bon langage pour le bon usage.
Si on veut un langage unique, on en assume le prix.

Quel intérêt que le comportement soit consistant s'il faut l'éviter ?

Ne serait ce que pour débugger, le fait d'avoir un comportement reproductible simplifie considérablement la vie.

En revanche, en JS, ces utilisations à éviter sont contre-intuitives, vont à l'encontre de grands principes de programmation, et il faut au moins s'être fait avoir une fois, avoir perdu un après-midi pour cette bêtise, pour le savoir.

C'est sans doute juste que tu as l'habitude du C. Je ne vois pas en quoi les opérations qui produisent des résultats surprenant en JS sont moins intuitives que certains Undefined Behavior en C.

[Neckara]

Rien! Aucun langage n'est parfaitement adapté à 100% des cas et puis c'est tout. C'est pour cela qu'il y en a plusieurs.
C ne fait pas exception à la règle.

Ouais, enfin là on ne parle pas de "points forts" ou de "points faible", mais carrément d'erreurs à la conception du langage.

C'est comme justifier le fait que e.g. dans un langage a = a incrémente a, au prétexte que peut de personnes n'utilise cela, et de dire que si on veut quand même le faire, il faut changer de langage.
C'est ridicule.

Note: a = a peut être utilisé sous cette forme : a[k] = a[k] || 0.

Bas si il y a des gens assez con pour utiliser JavaScript sur serveur alors que rien ne les y oblige c'est leur problème. Comme je l'ai dis, il faut faire le choix du bon langage pour le bon usage.
Si on veux un langage unique, on en assume le prix.

Ouais, enfin ces "surprises", tu les découvres un peu tardivement, et quand bien même tu n'as pas besoin de décalage de bits à un instant t, rien ne te dit que tes besoins ne vont pas évoluer au court du temps.

C'est sans doute juste que tu as l'habitude du C. Je ne vois pas les opérations qui produisent des résultats surprenant en JS sont plus naturelles que les UB en C.

Je ne comprends pas le sens de ta phrase.

[Uther]

Ouais, enfin là on ne parle pas de "points forts" ou de "points faible", mais carrément d'erreurs à la conception du langage.

La il faudrait que tu précise de quoi tu parles parce que c'est plutôt vague, rien t’empêche de faire du bit shifting en JS, même si c'est un peu plus compliqué si tu n'est pas en 32 bit.

Quant a l'égalité, j'ai du mal a voir ou tu veux en venir

Je ne comprends pas le sens de ta phrase.

En effet, je me suis emmêlé, j'ai édité pour corriger.

[Neckara]

La il faudrait que tu précise de quoi tu parles parce que c'est plutôt vague, rien t’empêche de faire du bit shifting en JS, même si c'est un peu plus compliqué si tu n'est pas en 32 bit.

Tu as le bit de signe qui se balade n'importe comment lorsque tu fais du bit shifting.
Et il me semble que tu ne peux réellement utiliser que 31bits au lieu de 32 bits à cause justement de ce bit de signe qui se balade n'importe comment.

Quant a l'égalité, j'ai du mal a voir ou tu veux en venir

C'était un exemple absurde pour mettre en relief l'absurdité de JS.

C'est sans doute juste que tu as l'habitude du C. Je ne vois pas en quoi les opérations qui produisent des résultats surprenant en JS sont moins intuitives que les UB en C.

En C, par exemple, si tu vas en dehors de l'index, tu as un comportement indéterminé, mais c'est normal, tu dépasses l'index. Soit tu as une erreur de segmentation (si tu tapes en dehors de la zone mémoire allouée), ou un nombre presque aléatoire (valeur lue dans la mémoire). Si tu divises par 0, le comportement est indéfini, cela ne vient pas du langage, mais du processeur/OS qui gère l'erreur. Les valeurs non-initialisée, c'est juste qu'elles ne sont pas initialisée, ce pour des raisons de performances. Le déréférencent de NULL, est lié au fait que 0x00..00 est aussi une adresse mémoire (cf dépassement d'index). Pour les entiers signés qu'on incrémente au-delà de leur valeur maximale, cela est encore dû au processeur. Modifier un string litteral est une erreur, car la string devrait être considérée constante.

Rien n'est donc vraiment surprenant.
En C, tu es très proche du matériel, si tu comprends le matériel, tout est assez intuitif.


En revanche, en JS, le bit de signe qui se balade lors des décalage de bits, c'est juste complètement fou et incohérent.
La gestion de '==' en JS, est complètement délirante:

Code :

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

1
2
3
4
5
6
7
' \t\r\n ' == 0 // true

'' == '0' // false    
0 == '' // true
0 == '0' // true

[] == ![]; // -> true

C'est complètement pêté.

[Uther]

Tu as le bit de signe qui se balade n'importe comment lorsque tu fais du bit shifting.

Il faudrait que tu précises le problème parce que je vois rien d'incohérent si on sait que les opération binaires sont en 32 bit.

La gestion de '==' en JS, est complètement délirante

Ne compte pas sur moi pour dire du bien du typage et des conversion de JS, mais ne pas accepter que les nombreux UB de C sont tout autant des pièges, ça me semble relever du syndrome de Stockholm.

[Neckara]

Il faudrait que tu précises le problème parce que je vois rien d'incohérent si on sait que les opération binaires sont en 32 bit.

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

Ne compte pas sur moi pour dire du bien du typage et des conversion de JS, mais ne pas accepter que les nombreux UB de C sont tout autant des pièges, ça me semble relever du syndrome de Stockholm.

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

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

[frfancha]

La gestion de '==' en JS, est complètement délirante:

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

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

[Neckara]

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

En effet, je découvres.

Bon, tous les autres langages définissent des entiers non-signés, qui n'ont pas ce genre de comportement, donc on est quand même sauvé.


Purée, tu viens de me red pill.