Posté par abriotde .
Évalué à 3.
Dernière modification le 09 mars 2023 à 14:07.
Je pense que la critique faite sur Rust est fondée, cependant, tout langage a des défauts. Zig est peut-être un peu plus rapide (pas de beaucoup) surtout sur des cas très spécifiques et optimisés bas niveau (Je pense notamment à la critique sur l'allocateur de mémoire custom). Par contre même si sur un point précis Zig peut-être un poil plus sûre que Rust , dans l'ensemble je n'y crois pas une seconde.
D’une manière générale, avec un exemple bien forgé, tu peux « prouver » un peu tout et n’importe quoi.
L’un des exemples du genre qui tournait pas mal il y a dix ans, c’est un algo qui était plus performant en Java qu’en C++. L’astuce, c’est que l’algo créait et libérait énormément de tous petits objets en mémoire tout en étant « facile » à compiler et optimiser pour un compilateur JIT. Donc, le code C++ passait son temps en appels système pour demander et libérer de la mémoire, tandis que la JVM avait demandé une allocation globale au tout début et passait son temps à jouer dans sa mémoire déjà réservée, ce qui est (était ?) plus rapide. C’était rigolo, ça faisait un programme plus rapide en Java qu’en C++ (sans tricher en désactivant les optimisations de compilation C++), mais ça n’était en rien représentatif d’un cas réel.
On commence à avoir des retours un peu critiques sur Rust de gens qui l'ont suffisament utilisé pour voir où sont ses limites, et dans quels cas il vaut mieux choisir un autre langage. C'est plutôt bon signe pour la maturité du langage.
Je n'ai pas trouvé ça exagéré, l'auteur s'est volontairement placé dans une situation où il savait que Rust allait poser problème, pour voir comment un autre langage pouvait s'y prendre dans ce cas précis. ÇA ne remet pas en cause l'utilisation de Rust dans plein d'autres cas (tous ceux où il n'y a pas besoin d'écrire de code "unsafe", c'est à dire probablement une très grande partie du code, tout le monde n'écrit pas des allocateurs ramasse-miettes, des machines virtuelles ou des systèmes d'exploitation).
D'autant plus que certains le font, d'implémenter des OS en rust. Du coup je serais curieux de voir les réactions des devs de redox a ce sujet (j'imagine qu'il n'en ont pas, de toute façon il ne serait probablement pas pertinent de changer le projet pour "si peu").
Quand on veut remplacer C/C++ qui sert à tout, il faut savoir tout faire :-)
1) C/C++ ce sont 2 langages, et C ne sert pas à tout ni C++ (même s'ils sont proche et assez complémentaires). Ensuite même le coupel C/C++ ne sert pas à tout. Il ne sert pas (où si peu sur le web entre autre)
2) Ensuite Rust n'a jamais déclarer remplacer C/C++, il se trouve justement qu'il le fait très bien (surtout C++ d'ailleurs). Et en aucun cas C/C++ disparaitront. D'aileurs COBOL, VB, Pascal, Awk… quasiment aucun langage ayant atteint une certaine popularité n'a dispatrût. Il suffit que Rust ait suffisamment d'avantages pour éclipser C/C++ sur une partie pour faire un exploit. Et ça il l'a déjà réussit.
3) C/C++ ne semblent pas meilleurs que Rust pour le garbage collector ou l'OS, on parles plus de Zig et c'est loin d'être démontré.
Rust sait faire tout ce que sait faire C/C++ et mieux dans 80% des cas et dans les 20% restant pas pire de ce que j'ai vu.
Posté par totof2000 .
Évalué à 8.
Dernière modification le 09 mars 2023 à 18:18.
Quand j'ai commencé à me mettre à Python, j'ai été assez vite séduit, cependant, je me suis vite rendu compte que python "forçait" à faire les choses à sa façon, et je me suis retrouvé à devoir me faire des noeuds au cerveau et à faire des trucs dégueulasses, ou beaucoup trop verbeux, parce que la façon de faire de python était trop rigide. Faire les mêmes choses en Ruby me posait moins de problème : je n'avais pas l'impression d'être dans le carcan Python.
Tout celà pour dire que bien souvent un langage donné va permettre de faire des choses dans un certain contexte (celui pour lequel il a été pensé), mais va poser problème dans un autre contexte. Rust a été écrit pour écrire du code safe, et rend difficile l'écriture de code non safe. Ca ne me choque pas plus que ça. Est-ce volontaire ? Je ne pense pas : c'est juste une conséquence de sa conception initiale. Peut-être qu'à l'avenir les concepteurs du langage faciliteront la vie des développeurs qui doivent écrire du code non ssfe … ou pas. Et dans ce cas, en attendant vaut-il mieux peut-être utiliser un autre langage pour écrire plus facilement les parties de code non safe avec les batteries de test adéquates ? Car je partage l'avis de l'auteur : il est peut-être plus dangereux d'écrire du code non safe en Rust qu'en C … tout comme il peut être dangereux d'utiliser un couteau de cuisine pour ouvrir une boite de conserve. Ce n'est pas fait pour.
Tout celà pour dire que bien souvent un langage donné va permettre de faire des choses dans un certain contexte […]
Je répond a ce paragraphe, pas juste a cette citation.
Je n'ai également aucune connaissance sur Rust ou Zig… en tout cas, je ne considère pas le fait d'avoir entendu parler de ces langages et de leurs objectifs comme une connaissance (et encore moins une compétence!).
Bref, maintenant que j'ai explicité mon contexte personnel, commençons.
Pour commencer, l'article originel ne dit pas que Zig est plus sûr que Rust: il dit que Zig est plus sûr que les sections unsafe de Rust, notamment grâce à la présence d'outils plus développés.
Vu que Zig est, de ce que j'ai lu, (sans jamais prêter trop d'attention) comparable à un fork du C, il ne serait pas étonnant qu'en effet, les outils C y soient adaptés, par exemple coccinelle qui n'est pas utilisable en C++, non plus (et celui-la vraiment, j'aimerai bien: je connais quelques jeux codés en C++ qui bénéficieraient d'un bon gros refactoring, et l'outil sert justement à ça).
Zig et Rust ont beau être «de la même génération» il n'empêche que l'un est un héritier (Zig) tandis que l'autre est un langage construit de zéro (si l'on exclue les décennies d'expériences, bien sûr).
En gros, la ou C++ et Zig sont des évolutions du C, Rust est un langage nouveau, qui n'a pas été conçu pour tourner sur du bare-metal, contrairement au C. C'est à dire, je crois savoir que Rust à été conçu pour améliorer les perfs et la maintenance de Firefox au 21ème siècle, alors que C aurait lui été conçu dès le départ (c'est à dire fin du 20ème, il y a plus de 50ans) pour construire un système d'exploitation.
Il y a donc (à ma connaissance) 2 grosses variables à prendre en compte:
le but. Créer un OS, ça implique créer un kernel, quoiqu'en dise GNU. Et un kernel, c'est quand même pas mal de code "pas sécurisé" (d'autres diraient "bas niveau", ce qui me semble un peu moins… mesquin. A défaut de meilleur mot. Je suis claqué, désolé.). Le C possède la capacité intrinsèque d'intégrer de l'assembleur, par exemple, et il arrive que ça soit utile (c'est un peu comme goto… on évite, mais rester dogmatique a parfois des effets pires);
l'âge du capitaine. C, le "capitaine" de Zig, a 50 ans, et un éco-système qui a été développé pendant ces 50 ans, également. Zig, de ce que j'ai lu reste plus «dans les clous» que C++, il me semble donc très possible qu'il bénéficie encore plus de tout cet écosystème que C++. Je ne sais pas à quel point Rust est compatible avec, mais je doute que la compatibilité soit élevée.
Bon, en lisant un peu, je me dis que des utilisateurs de lisp pourraient ne pas être d'accord avec l'auteur par contre:
Here are two monstrosities I found in the code:
// The way to make these readable is to create a variable for each dereference,
// but that's annoying so in some places I got lazy.
// ew
(*(*closure.as_ptr()).upvalues.as_ptr().offset(i as isize)) = upvalue;
// ewwwwww
let name = (*(*(*ptr.cast::<ObjBoundMethod>().as_ptr()).method.as_ptr())
.function
.as_ptr()).name;
J'imagine que l'abus de parenthèses ne gêne pas tout le monde? :)
Bon, je m'arrête à la lecture du 1er tier, je pense que, globalement, l'article est intéressant (je m'arrête parce que je suis rincé, je finirai peut-être plus tard, en plus ce message est déjà bien assez long), et soulève des points intéressants, notamment le fait que des langages «pas sûrs» soient plus appropriés pour du code bas niveau.
Ca semble enfoncer une porte ouverte, mais je reconnaît que cette évidence m'avait un peu échappé… et du coup les questions qui me viennent, c'est: que penser, spécifiquement, de Redox et du fait que Linux accepte l'usage de Rust dans certaines sections du projet (les pilotes, bien que j'imagine qu'ils doivent utiliser le principe du sablier pour être appelables par le noyau)?
PS: il faut vraiment que je prenne plus le temps d'écrire sans anglicisme, l'exercice m'est étonnamment difficile…
…ce qui est très bien pour le temps hein (mais pas glop en terme de mémoire.)
Par contre, le code Haskel est passé en multi cœurs …et on le compare au même code C mono cœur, super :D
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Ouai, en gros haskell est juste à l'ouest: plus lent malgré le parallélisme, et bouffe le double de ram.
Ton message était censé promouvoir haskell, ou l'enfoncer?
Les deux : dénoncer le titre et saluer quand même la prouesse (il s'agit de code écrit rapidement, plutôt sans y passer la journée, itérativement et avec des bibliothèques de base.) Attention, la version parallélisée est bien plus rapide ; je n'ai juste pas repris les chiffres (d'autant que je dénonce la concurrence déloyale à partir de là.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Critique justifiée mais exagérée
Posté par abriotde . Évalué à 3. Dernière modification le 09 mars 2023 à 14:07.
Je pense que la critique faite sur Rust est fondée, cependant, tout langage a des défauts. Zig est peut-être un peu plus rapide (pas de beaucoup) surtout sur des cas très spécifiques et optimisés bas niveau (Je pense notamment à la critique sur l'allocateur de mémoire custom). Par contre même si sur un point précis Zig peut-être un poil plus sûre que Rust , dans l'ensemble je n'y crois pas une seconde.
[^] # Re: Critique justifiée mais exagérée
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5.
D’une manière générale, avec un exemple bien forgé, tu peux « prouver » un peu tout et n’importe quoi.
L’un des exemples du genre qui tournait pas mal il y a dix ans, c’est un algo qui était plus performant en Java qu’en C++. L’astuce, c’est que l’algo créait et libérait énormément de tous petits objets en mémoire tout en étant « facile » à compiler et optimiser pour un compilateur JIT. Donc, le code C++ passait son temps en appels système pour demander et libérer de la mémoire, tandis que la JVM avait demandé une allocation globale au tout début et passait son temps à jouer dans sa mémoire déjà réservée, ce qui est (était ?) plus rapide. C’était rigolo, ça faisait un programme plus rapide en Java qu’en C++ (sans tricher en désactivant les optimisations de compilation C++), mais ça n’était en rien représentatif d’un cas réel.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Critique justifiée mais exagérée
Posté par Lutin . Évalué à 4.
Plus qu'une critique, c'est une expérience amusante (même si l'article fini en queue de poisson).
Je me demande ce que Zig va donner sur le long terme, la version 1 est prévue pour 2025.
[^] # Re: Critique justifiée mais exagérée
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7.
On commence à avoir des retours un peu critiques sur Rust de gens qui l'ont suffisament utilisé pour voir où sont ses limites, et dans quels cas il vaut mieux choisir un autre langage. C'est plutôt bon signe pour la maturité du langage.
Je n'ai pas trouvé ça exagéré, l'auteur s'est volontairement placé dans une situation où il savait que Rust allait poser problème, pour voir comment un autre langage pouvait s'y prendre dans ce cas précis. ÇA ne remet pas en cause l'utilisation de Rust dans plein d'autres cas (tous ceux où il n'y a pas besoin d'écrire de code "unsafe", c'est à dire probablement une très grande partie du code, tout le monde n'écrit pas des allocateurs ramasse-miettes, des machines virtuelles ou des systèmes d'exploitation).
[^] # Re: Critique justifiée mais exagérée
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Tout le monde non, mais ce sont des cas d'utilisation de Rust non ? Quand on veut remplacer C/C++ qui sert à tout, il faut savoir tout faire :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Critique justifiée mais exagérée
Posté par freem . Évalué à 3.
D'autant plus que certains le font, d'implémenter des OS en rust. Du coup je serais curieux de voir les réactions des devs de redox a ce sujet (j'imagine qu'il n'en ont pas, de toute façon il ne serait probablement pas pertinent de changer le projet pour "si peu").
[^] # Re: Critique justifiée mais exagérée
Posté par abriotde . Évalué à 1.
1) C/C++ ce sont 2 langages, et C ne sert pas à tout ni C++ (même s'ils sont proche et assez complémentaires). Ensuite même le coupel C/C++ ne sert pas à tout. Il ne sert pas (où si peu sur le web entre autre)
2) Ensuite Rust n'a jamais déclarer remplacer C/C++, il se trouve justement qu'il le fait très bien (surtout C++ d'ailleurs). Et en aucun cas C/C++ disparaitront. D'aileurs COBOL, VB, Pascal, Awk… quasiment aucun langage ayant atteint une certaine popularité n'a dispatrût. Il suffit que Rust ait suffisamment d'avantages pour éclipser C/C++ sur une partie pour faire un exploit. Et ça il l'a déjà réussit.
3) C/C++ ne semblent pas meilleurs que Rust pour le garbage collector ou l'OS, on parles plus de Zig et c'est loin d'être démontré.
Rust sait faire tout ce que sait faire C/C++ et mieux dans 80% des cas et dans les 20% restant pas pire de ce que j'ai vu.
[^] # Re: Critique justifiée mais exagérée
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 13 mars 2023 à 13:21.
Pour le web, il y a les serveurs web et les programmes CGI de la glorieuse époque. C'était pour rajouter une précision peu utile.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Ca me fait penser un peu à ce que j'ai vécu à un moment avec Python .....
Posté par totof2000 . Évalué à 8. Dernière modification le 09 mars 2023 à 18:18.
Quand j'ai commencé à me mettre à Python, j'ai été assez vite séduit, cependant, je me suis vite rendu compte que python "forçait" à faire les choses à sa façon, et je me suis retrouvé à devoir me faire des noeuds au cerveau et à faire des trucs dégueulasses, ou beaucoup trop verbeux, parce que la façon de faire de python était trop rigide. Faire les mêmes choses en Ruby me posait moins de problème : je n'avais pas l'impression d'être dans le carcan Python.
Tout celà pour dire que bien souvent un langage donné va permettre de faire des choses dans un certain contexte (celui pour lequel il a été pensé), mais va poser problème dans un autre contexte. Rust a été écrit pour écrire du code safe, et rend difficile l'écriture de code non safe. Ca ne me choque pas plus que ça. Est-ce volontaire ? Je ne pense pas : c'est juste une conséquence de sa conception initiale. Peut-être qu'à l'avenir les concepteurs du langage faciliteront la vie des développeurs qui doivent écrire du code non ssfe … ou pas. Et dans ce cas, en attendant vaut-il mieux peut-être utiliser un autre langage pour écrire plus facilement les parties de code non safe avec les batteries de test adéquates ? Car je partage l'avis de l'auteur : il est peut-être plus dangereux d'écrire du code non safe en Rust qu'en C … tout comme il peut être dangereux d'utiliser un couteau de cuisine pour ouvrir une boite de conserve. Ce n'est pas fait pour.
[^] # Re: Ca me fait penser un peu à ce que j'ai vécu à un moment avec Python .....
Posté par freem . Évalué à 4.
Je répond a ce paragraphe, pas juste a cette citation.
Je n'ai également aucune connaissance sur Rust ou Zig… en tout cas, je ne considère pas le fait d'avoir entendu parler de ces langages et de leurs objectifs comme une connaissance (et encore moins une compétence!).
Bref, maintenant que j'ai explicité mon contexte personnel, commençons.
Pour commencer, l'article originel ne dit pas que Zig est plus sûr que Rust: il dit que Zig est plus sûr que les sections
unsafede Rust, notamment grâce à la présence d'outils plus développés.Vu que Zig est, de ce que j'ai lu, (sans jamais prêter trop d'attention) comparable à un fork du C, il ne serait pas étonnant qu'en effet, les outils C y soient adaptés, par exemple coccinelle qui n'est pas utilisable en C++, non plus (et celui-la vraiment, j'aimerai bien: je connais quelques jeux codés en C++ qui bénéficieraient d'un bon gros refactoring, et l'outil sert justement à ça).
Zig et Rust ont beau être «de la même génération» il n'empêche que l'un est un héritier (Zig) tandis que l'autre est un langage construit de zéro (si l'on exclue les décennies d'expériences, bien sûr).
En gros, la ou C++ et Zig sont des évolutions du C, Rust est un langage nouveau, qui n'a pas été conçu pour tourner sur du bare-metal, contrairement au C. C'est à dire, je crois savoir que Rust à été conçu pour améliorer les perfs et la maintenance de Firefox au 21ème siècle, alors que C aurait lui été conçu dès le départ (c'est à dire fin du 20ème, il y a plus de 50ans) pour construire un système d'exploitation.
Il y a donc (à ma connaissance) 2 grosses variables à prendre en compte:
Bon, en lisant un peu, je me dis que des utilisateurs de lisp pourraient ne pas être d'accord avec l'auteur par contre:
J'imagine que l'abus de parenthèses ne gêne pas tout le monde? :)
Bon, je m'arrête à la lecture du 1er tier, je pense que, globalement, l'article est intéressant (je m'arrête parce que je suis rincé, je finirai peut-être plus tard, en plus ce message est déjà bien assez long), et soulève des points intéressants, notamment le fait que des langages «pas sûrs» soient plus appropriés pour du code bas niveau.
Ca semble enfoncer une porte ouverte, mais je reconnaît que cette évidence m'avait un peu échappé… et du coup les questions qui me viennent, c'est: que penser, spécifiquement, de Redox et du fait que Linux accepte l'usage de Rust dans certaines sections du projet (les pilotes, bien que j'imagine qu'ils doivent utiliser le principe du sablier pour être appelables par le noyau)?
PS: il faut vraiment que je prenne plus le temps d'écrire sans anglicisme, l'exercice m'est étonnamment difficile…
# Beating C with 80 lines of Haskell
Posté par steph1978 . Évalué à 3.
https://chrispenner.ca/posts/wc
[^] # Re: Beating C with 80 lines of Haskell
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
En vrai, au final :
wcen C…ce qui est très bien pour le temps hein (mais pas glop en terme de mémoire.)
Par contre, le code Haskel est passé en multi cœurs …et on le compare au même code C mono cœur, super :D
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Beating C with 80 lines of Haskell
Posté par freem . Évalué à 4.
Ouai, en gros haskell est juste à l'ouest: plus lent malgré le parallélisme, et bouffe le double de ram.
Ton message était censé promouvoir haskell, ou l'enfoncer?
[^] # Re: Beating C with 80 lines of Haskell
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 10 mars 2023 à 00:19.
Les deux : dénoncer le titre et saluer quand même la prouesse (il s'agit de code écrit rapidement, plutôt sans y passer la journée, itérativement et avec des bibliothèques de base.) Attention, la version parallélisée est bien plus rapide ; je n'ai juste pas repris les chiffres (d'autant que je dénonce la concurrence déloyale à partir de là.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Beating C with 80 lines of Haskell
Posté par freem . Évalué à 2.
c'est plus clair, merci :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.