Ah ben si c'est Microsoft qui le dit, j'arrête le C immédiatement. Après tout, sur mon ESP32-S3 j'ai pas besoin de compter le nombre d'octets que je créé sur ma pile d'appel, il a une taille de de 8096 octets, bien assez pour faire tourner n'importe quel langage à boite noire !
À mort le C !
git is great because linus did it, mercurial is better because he didn't
Je meurs d'envie de savoir comment tu fais. Ici, on doit optimiser le moindre appel en mettant le moins possible de variables sur la pile d'appel pour éviter un panic. Après on a laissé les paramètres par défaut et peut-être qu'on peut “enlarge my stack” s'il faut. En tout cas on a revu notre approche en favorisant parfois les allocations dynamiques même quand on aurait aimé s'en passer.
git is great because linus did it, mercurial is better because he didn't
La taille des objets mis sur la stack est connue en rust a la compilation, c'est même une erreur de compilation quand c'est pas le cas. Que l'architecture soit pas gérée par le compilateur je comprends, mais ta remarque sur la taille de la stack pas vraiment, et s'il faut être économe tu as de premier abord les mêmes possibilités (passer des pointeurs vers des trucs en heap, utiliser des types peu gourmands comme des int16) qu'en C… Tu peux détailler ce qui rend rust pas gérable côté stack, c'est la première fois que je lis ça et je vois mal le problème ? Surtout que le compilo me fait bien chier quand il me saoule avec ces histoires de tailles pas connues a la compilation :)
Mark Russinovich, the chief technology officer of Microsoft Azure, says developers should avoid using C or C++ programming languages in new projects and instead use Rust because of security and reliability concerns.
Et moi je dis que les utilisateurs devraient éviter d'utiliser le système d'exploitation Windows dans leur nouveaux équipements et plutôt utiliser Linux pour des raisons de sécurité et de fiabilité.
Pour ceux qui ne le connaissent pas, Mark est une pointure reconnue dans le coté technique du monde Windows. Allez lire sa biographie et vous comprendrez qu'il n'est pas là pour brasser du vent.
On en reparle le jour ou les technos modernes sont stables dans la duree? c'est pas que j'aime pas RUST mais je sent que l'effort de maintenance va exploser :)
Posté par Zenitram (site web personnel) .
Évalué à 10.
Dernière modification le 23 septembre 2022 à 14:43.
Perso du haut de mon âge, j'ai vu passer Java, puis C#/Mono, puis Python, puis Rust comme langage à utiliser et laisser C/C++. J'attends donc le prochain conseil et continue avec C/C++, pas parfait mais au moins je continue mon projet sans perdre du temps à changer de langage tous les 5 ans.
Il y a certes des pièges avec mais il y en a aussi avec kes autres quand on creuse.
Malheureusement C# et Java restent des langages qui font “enterprisy” et toujours enseigné dans les écoles. On va avoir du mal à enterrer ces langages tant que ce modèle n'évolue pas.
Pour certains c'est impensable de quitter ces langages juste parce que derrière il y a des grosses entreprises qui poussent au développement. C'est dommage.
Combien de fois j'ai entendu « nous utilisons exchange parce que c'est microsoft » au lieu d'utiliser un simple postfix/opensmtpd… Je suppose que c'est parfois pareil avec les technologies, tout domaine confondu.
git is great because linus did it, mercurial is better because he didn't
C’est pas du tout mon propos : Java, C#/Mono ou Python sont d’excellents langages dans leurs domaines d’application, surtout dans leurs dernières versions ; et comme dit ci-dessus, ils évoluent assez rapidement.
Non, mon propos, c’est que je suis étonné que l’on puisse proposer ces langages pour remplacer C ou C++.
Je sais par exemple que C# ou Java ont pu remplacer les utilisations les plus « haut niveau » de C++, mais pour moi aucun des langages de la liste n’a jamais été un candidat sérieux au remplacement de C++ pour les projets orienté performance, et encore moins au remplacement de C.
99% des projets ne sont pas orientés performances, et ensuite on s'étonne que notre PC ou smartphone (qui ont 99% de petits logiciels pas orientés performance qui tournent en tâche de fond) rame (en parlant de rame, qui bouffe aussi plein de RAM).
Je fais une différence entre « essayer de de pas consommer comme un sac en faisant n’importe quoi » et « la majorité de l’effort sur mon projet concerne les performances ».
Ce que j’appelle « orienté performances », c’est ce deuxième cas, où tu es obligé d’utiliser des langages qui te permettent une gestion fine des ressources sans quoi le résultat est vraiment déraisonnable.
+1, ça fait tellement longtemps que l'on met la performance au second plan à grand coups de « premature optimization is the root of all evil » qu'on en vient à tout pessimiser. Même en C++ je vois encore plein de std::list là où un std::vector serait mieux, des std::map là où il faudrait utiliser std::unordered_map, des paramètres passés par valeur… Je ne parle même pas de faire des optims algorithmiques ou bas niveau ; juste d'utiliser de meilleurs outils par défaut.
Maintenant, parlons de la stdlib du C++, qui a attendu C++11 pour avoir une hash map. Tout le monde s'attend à ce qu'une map soit hashé sur les clés avec un ordre non garanti sur l'itération (oui, même si Python a changé d'avis), permettant d'avoir un temps amorti sur la recherche. C'est dommage je trouve. J'ai été très perturbé d'avoir des std::map au comportement si différent des autres langages.
Peut-être que j'ai été trop drogué au HashMap de Java et de Perl ?
Le mot important c'est 'premature' pas 'optimisation'. Ce que je comprends de cette phrase c'est plus mesurez ce que vous optimisez et commencez pas par ça, codez juste avant de codez rapide, et évaluez le coût…
Que celui qui n'a jamais optimisé la mauvaise fonction pour gagner moins de temps d'exécution totale que le temps passé a optimiser me jete la première pierre.
Le fameux cycle du hype. Je souhaite à Rust d'arriver rapidement à la 4ème puis à la cinquième phase sans trop souffrir des deux précédentes.
Java, Python et C# en sont déjà passé par là, maintenant ils ont trouvé leur place. Ils ont probablement pris une partie de la place qui était occupée il y a 20 ou 30 ans par C ou C++, qui sont maintenant plutôt utilisés dans les applications ou il y a besoin de performance, alors qu'avant ils étaient utilisés vraiment partout (faute d'avoir beaucoup d'autre choix et parce que le matériel disponible à l'époque faisait que toutes les applications avaient un peu plus besoin de faire attention aux performances).
Il semble qu'on aura une phase de "c'est trop génial ça va tout remplacer" à la sortie de chaque nouveau langage.
Posté par Zenitram (site web personnel) .
Évalué à -3.
Dernière modification le 23 septembre 2022 à 20:03.
maintenant ils ont trouvé leur place
Mais du coup dans 100 ans on a 100 langages à la dernière phase, super la division. Surtout diviser pour mieux régner. A un moment faudrait écrémer (Perl prend mal quand même, c'est déjà ça; et C# est devenu de niche).
Bon, en attendant, mon gros avantage de vieux codeur C/C++ c'est que je peux facilement proposer un binding pour tous les nouveaux langages, chacun se forçant à avoir quand même un lien avec le C/C++ (surtout le C mais ça suffit), ce que ne peuvent pas faire les autres (d'où segmentation négative en comparaison; je verrai ce que je ferai quand je prendrai ma retraite).
Je dirais que le langage est encore relativement jeune et qu'on manque un peu de recul sur les choses qui pourraient mal se passer avec.
Et aussi que c'est compliqué pour l'instant de trouver des gens avec un peu d'expérience en Rust pour bien architecturer les nouveaux projets dès le départ.
C'est sympa de la part de Microsoft de prendre les devants et de faire ces expériences pour nous :)
Et aussi que c'est compliqué pour l'instant de trouver des gens avec un peu d'expérience en Rust pour bien architecturer les nouveaux projets dès le départ.
Après plus d'un an à écrire du Rust, je me suis rendu compte d'une chose :
Rust n'est pas un langage "general purpose".
Il vise la programmation système, de bas niveau (en utilisant des concepts de haut niveau le plus possible), la ou on a un besoin d'un contrôle précis sur les performances, les allocations, etc… (osdev, gamedev, real time systems, etc…).
A cause de ça, le language reste un langage de niche. On est très très loin des API CRUD faite en autre chose que Java, Python et/ou Go (qui est un langage safe aussi, mais avec d'autres tradeoffs).
Je suis tout à fait d'accord avec toi. Rust est très sécurisé, mais difficile à utiliser. Pour remplacer le C et le C++, le pense que Nim, Zig ou V, sont mieux car, plus simple d'utilisation, tout en aillant les outils moderne, sans GC, et surtout rapide à l’exécution. Carbon aussi pourrait être intéressant, mais il n'est pas encore disponible.
vous savez que les applications qui monitorent/contrôlent les réacteurs nucléaires, ou machines médicales à rayons X, ou autre trucs qui peuvent tuer des gens sont minoritaires ?
Toutes les applications ne sont pas critiques. Le C est un important language a avoir dans sa besace, et il reste invaincu en termes de performance, il reste le language le plus proche qui soit de la machine, il reste le seul langage aussi portable sur tant d'architectures complètement différentes (car il n'y a pas que x86 dans la vie), etc…
Bref, merci de la leçon de morale, j'aurais pu m'en passer.
D'autant plus pour un éditeur d'au moins 3 plateformes (windows, azure, xbox). C'est pas anormal de donner son avis. Surtout qu'on peut pas les taxer de mettre en avant un de leur produit (comme ça pourrait être le cas avec C# ou F# par exemple).
L'analyse statique ne fais que ce qu'elle peut quand le langage ne te donne pas la sémantique de ce que tu veux analyser. D'après-toi, pourquoi est-ce que ces solutions ne sont pas incluses dans gcc ou clang ? Pourquoi est-ce que c'est à ajouter à ton processus de build et pas directement inclut dans ton installation et activé avec un -pdantic ?
vous savez que les applications qui monitorent/contrôlent les réacteurs nucléaires, ou machines médicales à rayons X, ou autre trucs qui peuvent tuer des gens sont minoritaires ?
Les plus hautes sécurités ne sont pas liées au langage. C'est le processus de développement qui assure la qualité et non une silver bullet derrière la quelle on se sentirait protégé. Ça peut incorporer comment faire des tests, quand, sur quelle partie, comment suivre les défauts, la traçabilité des choix, ça peut inclure de la preuve de programme aussi, dans certains cas ça peut aller jusqu'à faire une enquête de de moralité des intervenants.
Aucune solution technique ne te protègera d'un bug fonctionnel hors dans les cas les plus critiques tu ne veux pas avoir de problème fonctionnel.
Vous savez que Rust n'a rien inventé ?
Comme tout langage rust est un équilibre choisi entre tout un tas de paramètres (sécurité mémoire, taille du runtime, sémantique du langage, système de type, etc) en prenant en compte l'état de l'art au moment de sa conception. L'équilibre choisi entre sécurité mémoire par défaut et légèreté du système de type le rend populaire.
C'est aussi bête de croire que rust résout toutes les difficultés sans surcoût que de se cacher les yeux en affirmant qu'il n'apporte rien.
C'est loin d'être au niveau de ce qui est pointé plus haut. En particulier aucune de ces options ne s'approche de ce que fait le borrow checker alors que splint si. Il faut ajouter pleins d'annotations à ton code, mais il fait des vérifications approchantes. Bon il n'a pas reçu de mises à jour ces 12 dernières années donc il maîtrise probablement bien moins de cas que le borrow checker de rust qui est régulièrement amélioré sur ce point.
Pourquoi est-ce que c'est à ajouter à ton processus de build et pas directement inclut dans ton installation et activé avec un -pdantic ?
-pedantic c'est plutôt pour le code de type "la spécification du langage dit que c'est interdit mais en fait ça marche quand même".
Ce type de chose serait plutôt détecté par les warnings activés par -Wextra, de type "la specification du langage dit que c'est autorisé, mais ça sert à rien à part écrire du code buggé".
Cependant il peut arriver que les warnings rangés dans -Wextra se déclenchent sur du code qui utilise volontairement un des aspects tordus du langage.
(ça n'enlève rien à l'intérêt des analyseurs statiques en plus du compilateur, ou d'utiliser des langages qui ont moins de chausse-trappes lorsque c'est possible)
Après pour faire la même chose il faut ajouter pas mal annotation dans ton code (pour utiliser le sharing de splint). Ça revient un peu à dire que les langages objets n'apportent rien face au C puisque le C++ ou l'ObjectiveC existent.
Il me semble même que c’est un peu la raison d’être de Rust :
A lot of obvious good ideas, known and loved in other languages, haven't made it into widely-used systems languages, or are deployed in languages that have very poor (unsafe, concurrency-hostile) memory models.
Autans ça fait depuis que j'ai commencer le dev, que je voie des gents dire qu'il faut arrêter le C, car tout les 5,6ans y’a une faille de sécurité majeur qui ne pourrais pas arrivé dans un langage qui n'a rien de "unsafe" comme Rust.
A chaque nouvelle fonctionnalité de C++, on entend des gents dire d’arrêter le C, à un tel point que ça ma fait pas aimer le C++, alors que j'aimais bien le langage.
mais c'est l'une des 1er fois que je voie quelqu'un mettre C et C++ dans le même panier. (alors que bon le C++11 et les suivant sont quand même assez safe(au moins autant que GNU C + static analyse)).
Bon bah les dev C++, bienvenue au club des gents qui utilise un langage non grata !
# Je change
Posté par David Demelier (site web personnel) . Évalué à 10.
Ah ben si c'est Microsoft qui le dit, j'arrête le C immédiatement. Après tout, sur mon ESP32-S3 j'ai pas besoin de compter le nombre d'octets que je créé sur ma pile d'appel, il a une taille de de 8096 octets, bien assez pour faire tourner n'importe quel langage à boite noire !
À mort le C !
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Je change
Posté par Dr BG . Évalué à 3.
EN tous cas, sur ESP32, je fais tourner du Java. Et mieux : du JavaScript que j'ai transpilé en Java ;)
[^] # Re: Je change
Posté par David Demelier (site web personnel) . Évalué à 2.
Je meurs d'envie de savoir comment tu fais. Ici, on doit optimiser le moindre appel en mettant le moins possible de variables sur la pile d'appel pour éviter un panic. Après on a laissé les paramètres par défaut et peut-être qu'on peut “enlarge my stack” s'il faut. En tout cas on a revu notre approche en favorisant parfois les allocations dynamiques même quand on aurait aimé s'en passer.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Je change
Posté par Fulgrim . Évalué à 4.
La taille des objets mis sur la stack est connue en rust a la compilation, c'est même une erreur de compilation quand c'est pas le cas. Que l'architecture soit pas gérée par le compilateur je comprends, mais ta remarque sur la taille de la stack pas vraiment, et s'il faut être économe tu as de premier abord les mêmes possibilités (passer des pointeurs vers des trucs en heap, utiliser des types peu gourmands comme des int16) qu'en C… Tu peux détailler ce qui rend rust pas gérable côté stack, c'est la première fois que je lis ça et je vois mal le problème ? Surtout que le compilo me fait bien chier quand il me saoule avec ces histoires de tailles pas connues a la compilation :)
[^] # Re: Je change
Posté par Thomas Debesse (site web personnel) . Évalué à 6. Dernière modification le 24 septembre 2022 à 16:34.
C’est le directeur technique d’Azure qui parle, tu n’es pas la cible de la recommandation.
Ton code n’est ni sensé tourner sur Azure, ni faire tourner Azure.
ce commentaire est sous licence cc by 4 et précédentes
# It's time to stop using Windows for new computers
Posté par nico4nicolas . Évalué à 10.
Et moi je dis que les utilisateurs devraient éviter d'utiliser le système d'exploitation Windows dans leur nouveaux équipements et plutôt utiliser Linux pour des raisons de sécurité et de fiabilité.
[^] # Re: It's time to stop using Windows for new computers
Posté par rycks . Évalué à 6.
Mais non ! voyons restons cohérents … passons tous à Redox ! https://fr.wikipedia.org/wiki/Redox_(syst%C3%A8me_d%27exploitation)
eric.linuxfr@sud-ouest.org
[^] # Re: It's time to stop using Windows for new computers
Posté par Tonton Th (Mastodon) . Évalué à 5.
Pour ceux qui ne le connaissent pas, Mark est une pointure reconnue dans le coté technique du monde Windows. Allez lire sa biographie et vous comprendrez qu'il n'est pas là pour brasser du vent.
[^] # Re: It's time to stop using Windows for new computers
Posté par Glandos . Évalué à 8.
Aaaah, je me souviens, j'utilisais ProcessExplorer de sysinternals.com fait par Mark Russinovich bien avant qu'il ne soit embauché chez Microsoft.
Et depuis, ProcessExplorer reste mieux que l'utilitaire fourni par Microsoft. Mais bon, hein, je dis ça, je dis rien :)
# La fin de la "stabilite" des standards ?
Posté par rzr (site web personnel) . Évalué à 7.
On en reparle le jour ou les technos modernes sont stables dans la duree? c'est pas que j'aime pas RUST mais je sent que l'effort de maintenance va exploser :)
Retours d'experiences bienvenus
gpg:0x467094BC
[^] # Re: La fin de la "stabilite" des standards ?
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 23 septembre 2022 à 14:43.
Perso du haut de mon âge, j'ai vu passer Java, puis C#/Mono, puis Python, puis Rust comme langage à utiliser et laisser C/C++. J'attends donc le prochain conseil et continue avec C/C++, pas parfait mais au moins je continue mon projet sans perdre du temps à changer de langage tous les 5 ans.
Il y a certes des pièges avec mais il y en a aussi avec kes autres quand on creuse.
[^] # Re: La fin de la "stabilite" des standards ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5.
Il y a vraiment des gens qui ont conseillé (ou conseillent toujours) d’utiliser Java, C#/Mono ou Python pour remplacer C++ et surtout C ?
Parce que c’est pas les mêmes domaines d’application !
La connaissance libre : https://zestedesavoir.com
[^] # Re: La fin de la "stabilite" des standards ?
Posté par David Demelier (site web personnel) . Évalué à 4.
Malheureusement C# et Java restent des langages qui font “enterprisy” et toujours enseigné dans les écoles. On va avoir du mal à enterrer ces langages tant que ce modèle n'évolue pas.
Pour certains c'est impensable de quitter ces langages juste parce que derrière il y a des grosses entreprises qui poussent au développement. C'est dommage.
Combien de fois j'ai entendu « nous utilisons exchange parce que c'est microsoft » au lieu d'utiliser un simple postfix/opensmtpd… Je suppose que c'est parfois pareil avec les technologies, tout domaine confondu.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: La fin de la "stabilite" des standards ?
Posté par David Delassus (site web personnel) . Évalué à 6.
C# et Java sont vraiment de bons langages, en constante évolution.
Je vois le C# beaucoup utilisé comme "scripting engine" dans le GameDev, qui se prête bien à la POO que proposent ces langages.
Je suis pas sûr d'ou viendrait une motivation à les enterrer, vu ce qu'ils apportent (CassandraDB est en Java).
Faut pas oublier que la JVM est hautement paramétrable, et que GraalVM va encore plus loin.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: La fin de la "stabilite" des standards ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4.
C’est pas du tout mon propos : Java, C#/Mono ou Python sont d’excellents langages dans leurs domaines d’application, surtout dans leurs dernières versions ; et comme dit ci-dessus, ils évoluent assez rapidement.
Non, mon propos, c’est que je suis étonné que l’on puisse proposer ces langages pour remplacer C ou C++.
Je sais par exemple que C# ou Java ont pu remplacer les utilisations les plus « haut niveau » de C++, mais pour moi aucun des langages de la liste n’a jamais été un candidat sérieux au remplacement de C++ pour les projets orienté performance, et encore moins au remplacement de C.
La connaissance libre : https://zestedesavoir.com
[^] # Re: La fin de la "stabilite" des standards ?
Posté par Zenitram (site web personnel) . Évalué à 2.
99% des projets ne sont pas orientés performances, et ensuite on s'étonne que notre PC ou smartphone (qui ont 99% de petits logiciels pas orientés performance qui tournent en tâche de fond) rame (en parlant de rame, qui bouffe aussi plein de RAM).
[^] # Re: La fin de la "stabilite" des standards ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5.
Je fais une différence entre « essayer de de pas consommer comme un sac en faisant n’importe quoi » et « la majorité de l’effort sur mon projet concerne les performances ».
Ce que j’appelle « orienté performances », c’est ce deuxième cas, où tu es obligé d’utiliser des langages qui te permettent une gestion fine des ressources sans quoi le résultat est vraiment déraisonnable.
La connaissance libre : https://zestedesavoir.com
[^] # Re: La fin de la "stabilite" des standards ?
Posté par Julien Jorge (site web personnel) . Évalué à 6.
+1, ça fait tellement longtemps que l'on met la performance au second plan à grand coups de « premature optimization is the root of all evil » qu'on en vient à tout pessimiser. Même en C++ je vois encore plein de
std::listlà où unstd::vectorserait mieux, desstd::maplà où il faudrait utiliserstd::unordered_map, des paramètres passés par valeur… Je ne parle même pas de faire des optims algorithmiques ou bas niveau ; juste d'utiliser de meilleurs outils par défaut.[^] # Re: La fin de la "stabilite" des standards ?
Posté par Glandos . Évalué à 5.
Je suis parfaitement d'accord.
Maintenant, parlons de la stdlib du C++, qui a attendu C++11 pour avoir une hash map. Tout le monde s'attend à ce qu'une map soit hashé sur les clés avec un ordre non garanti sur l'itération (oui, même si Python a changé d'avis), permettant d'avoir un temps amorti sur la recherche. C'est dommage je trouve. J'ai été très perturbé d'avoir des
std::mapau comportement si différent des autres langages.Peut-être que j'ai été trop drogué au
HashMapde Java et de Perl ?[^] # Re: La fin de la "stabilite" des standards ?
Posté par Fulgrim . Évalué à 5.
Le mot important c'est 'premature' pas 'optimisation'. Ce que je comprends de cette phrase c'est plus mesurez ce que vous optimisez et commencez pas par ça, codez juste avant de codez rapide, et évaluez le coût…
Que celui qui n'a jamais optimisé la mauvaise fonction pour gagner moins de temps d'exécution totale que le temps passé a optimiser me jete la première pierre.
[^] # Re: La fin de la "stabilite" des standards ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
Le fameux cycle du hype. Je souhaite à Rust d'arriver rapidement à la 4ème puis à la cinquième phase sans trop souffrir des deux précédentes.
Java, Python et C# en sont déjà passé par là, maintenant ils ont trouvé leur place. Ils ont probablement pris une partie de la place qui était occupée il y a 20 ou 30 ans par C ou C++, qui sont maintenant plutôt utilisés dans les applications ou il y a besoin de performance, alors qu'avant ils étaient utilisés vraiment partout (faute d'avoir beaucoup d'autre choix et parce que le matériel disponible à l'époque faisait que toutes les applications avaient un peu plus besoin de faire attention aux performances).
Il semble qu'on aura une phase de "c'est trop génial ça va tout remplacer" à la sortie de chaque nouveau langage.
[^] # Re: La fin de la "stabilite" des standards ?
Posté par Tonton Th (Mastodon) . Évalué à 3.
Et par Perl, qui semble tomber dans les oubliettes depuis quelques années…
[^] # Re: La fin de la "stabilite" des standards ?
Posté par Zenitram (site web personnel) . Évalué à -3. Dernière modification le 23 septembre 2022 à 20:03.
Mais du coup dans 100 ans on a 100 langages à la dernière phase, super la division. Surtout diviser pour mieux régner. A un moment faudrait écrémer (Perl prend mal quand même, c'est déjà ça; et C# est devenu de niche).
Bon, en attendant, mon gros avantage de vieux codeur C/C++ c'est que je peux facilement proposer un binding pour tous les nouveaux langages, chacun se forçant à avoir quand même un lien avec le C/C++ (surtout le C mais ça suffit), ce que ne peuvent pas faire les autres (d'où segmentation négative en comparaison; je verrai ce que je ferai quand je prendrai ma retraite).
[^] # Re: La fin de la "stabilite" des standards ?
Posté par BAud (site web personnel) . Évalué à 3.
bin tu pourras faire de l'Ada :-) ya tous les bindings que tu peux souhaiter _o/
Bon, autant le C tu peux démarrer en 1/2 h, pour Ada c'est plutôt (l'ami de Mickey) 1/2 journée :p
# Est-ce que c'est pas un peu tôt?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Je dirais que le langage est encore relativement jeune et qu'on manque un peu de recul sur les choses qui pourraient mal se passer avec.
Et aussi que c'est compliqué pour l'instant de trouver des gens avec un peu d'expérience en Rust pour bien architecturer les nouveaux projets dès le départ.
C'est sympa de la part de Microsoft de prendre les devants et de faire ces expériences pour nous :)
[^] # Re: Est-ce que c'est pas un peu tôt?
Posté par David Delassus (site web personnel) . Évalué à 7.
Après plus d'un an à écrire du Rust, je me suis rendu compte d'une chose :
Rust n'est pas un langage "general purpose".
Il vise la programmation système, de bas niveau (en utilisant des concepts de haut niveau le plus possible), la ou on a un besoin d'un contrôle précis sur les performances, les allocations, etc… (osdev, gamedev, real time systems, etc…).
A cause de ça, le language reste un langage de niche. On est très très loin des API CRUD faite en autre chose que Java, Python et/ou Go (qui est un langage safe aussi, mais avec d'autres tradeoffs).
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Est-ce que c'est pas un peu tôt?
Posté par David Demelier (site web personnel) . Évalué à 2.
Tout à fait. Mais en plus de ça à être si sécurisé il se prête plutôt mal au développement d'OS ou 1/4 du code du kernel sera dans un bloc
unsafe.git is great because linus did it, mercurial is better because he didn't
[^] # Re: Est-ce que c'est pas un peu tôt?
Posté par David Delassus (site web personnel) . Évalué à 6.
Avec ce 1/4 bien encapsulé dans une API safe, on a donc 3/4 du code qui est garanti safe par le compilateur.
Aussi : https://os.phil-opp.com/
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Est-ce que c'est pas un peu tôt?
Posté par vitanix . Évalué à 1.
Je suis tout à fait d'accord avec toi. Rust est très sécurisé, mais difficile à utiliser. Pour remplacer le C et le C++, le pense que Nim, Zig ou V, sont mieux car, plus simple d'utilisation, tout en aillant les outils moderne, sans GC, et surtout rapide à l’exécution. Carbon aussi pourrait être intéressant, mais il n'est pas encore disponible.
[^] # Re: Est-ce que c'est pas un peu tôt?
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 4.
C’est pas tôt, c’est vendredi :-)
[^] # Re: Est-ce que c'est pas un peu tôt?
Posté par Tonton Th (Mastodon) . Évalué à 3.
Ça fait deux jours que j'avais peur de me faire griller. Heureusement,
comp.lang.cétait au courant depuis deux jours :)# Le C a vécu 50 années, et vivra 50 de plus
Posté par David Delassus (site web personnel) . Évalué à 9.
Vous savez que Rust n'a rien inventé ?
Vous savez qu'il existe de nombreux outils pour s'assurer que le code est safe, comme :
vous savez que les applications qui monitorent/contrôlent les réacteurs nucléaires, ou machines médicales à rayons X, ou autre trucs qui peuvent tuer des gens sont minoritaires ?
Toutes les applications ne sont pas critiques. Le C est un important language a avoir dans sa besace, et il reste invaincu en termes de performance, il reste le language le plus proche qui soit de la machine, il reste le seul langage aussi portable sur tant d'architectures complètement différentes (car il n'y a pas que x86 dans la vie), etc…
Bref, merci de la leçon de morale, j'aurais pu m'en passer.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Le C a vécu 50 années, et vivra 50 de plus
Posté par Psychofox (Mastodon) . Évalué à 8. Dernière modification le 23 septembre 2022 à 15:45.
Je ne crois pas qu'il y ait de leçon de morale.
On parle d'une recomendation d'une entreprise.
[^] # Re: Le C a vécu 50 années, et vivra 50 de plus
Posté par barmic 🦦 . Évalué à 3.
D'autant plus pour un éditeur d'au moins 3 plateformes (windows, azure, xbox). C'est pas anormal de donner son avis. Surtout qu'on peut pas les taxer de mettre en avant un de leur produit (comme ça pourrait être le cas avec C# ou F# par exemple).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le C a vécu 50 années, et vivra 50 de plus
Posté par barmic 🦦 . Évalué à 8.
L'analyse statique ne fais que ce qu'elle peut quand le langage ne te donne pas la sémantique de ce que tu veux analyser. D'après-toi, pourquoi est-ce que ces solutions ne sont pas incluses dans gcc ou clang ? Pourquoi est-ce que c'est à ajouter à ton processus de build et pas directement inclut dans ton installation et activé avec un
-pdantic?Les plus hautes sécurités ne sont pas liées au langage. C'est le processus de développement qui assure la qualité et non une silver bullet derrière la quelle on se sentirait protégé. Ça peut incorporer comment faire des tests, quand, sur quelle partie, comment suivre les défauts, la traçabilité des choix, ça peut inclure de la preuve de programme aussi, dans certains cas ça peut aller jusqu'à faire une enquête de de moralité des intervenants.
Aucune solution technique ne te protègera d'un bug fonctionnel hors dans les cas les plus critiques tu ne veux pas avoir de problème fonctionnel.
Comme tout langage rust est un équilibre choisi entre tout un tas de paramètres (sécurité mémoire, taille du runtime, sémantique du langage, système de type, etc) en prenant en compte l'état de l'art au moment de sa conception. L'équilibre choisi entre sécurité mémoire par défaut et légèreté du système de type le rend populaire.
C'est aussi bête de croire que rust résout toutes les difficultés sans surcoût que de se cacher les yeux en affirmant qu'il n'apporte rien.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le C a vécu 50 années, et vivra 50 de plus
Posté par uso (site web personnel) . Évalué à 5.
https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Static-Analyzer-Options.html
[^] # Re: Le C a vécu 50 années, et vivra 50 de plus
Posté par barmic 🦦 . Évalué à 3.
C'est loin d'être au niveau de ce qui est pointé plus haut. En particulier aucune de ces options ne s'approche de ce que fait le borrow checker alors que splint si. Il faut ajouter pleins d'annotations à ton code, mais il fait des vérifications approchantes. Bon il n'a pas reçu de mises à jour ces 12 dernières années donc il maîtrise probablement bien moins de cas que le borrow checker de rust qui est régulièrement amélioré sur ce point.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le C a vécu 50 années, et vivra 50 de plus
Posté par uso (site web personnel) . Évalué à 0. Dernière modification le 25 septembre 2022 à 11:44.
Si tu parle de -fanalyzer, ca a étais ajouté pour gcc 10(2020), et c'est en constante évolution.
Après est-ce que c'est aussi puissant que rust, avec peu, ou aucun, unsafe, je pense pas.
Edit: j'ai relu ton commentaire, et vu que tu parlais de Splint… bon my bad.
[^] # Re: Le C a vécu 50 années, et vivra 50 de plus
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
-pedantic c'est plutôt pour le code de type "la spécification du langage dit que c'est interdit mais en fait ça marche quand même".
Ce type de chose serait plutôt détecté par les warnings activés par -Wextra, de type "la specification du langage dit que c'est autorisé, mais ça sert à rien à part écrire du code buggé".
Cependant il peut arriver que les warnings rangés dans -Wextra se déclenchent sur du code qui utilise volontairement un des aspects tordus du langage.
(ça n'enlève rien à l'intérêt des analyseurs statiques en plus du compilateur, ou d'utiliser des langages qui ont moins de chausse-trappes lorsque c'est possible)
[^] # Re: Le C a vécu 50 années, et vivra 50 de plus
Posté par barmic 🦦 . Évalué à 3.
Oui je suis allé un peu vite.
Après pour faire la même chose il faut ajouter pas mal annotation dans ton code (pour utiliser le sharing de splint). Ça revient un peu à dire que les langages objets n'apportent rien face au C puisque le C++ ou l'ObjectiveC existent.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le C a vécu 50 années, et vivra 50 de plus
Posté par Thomas Douillard . Évalué à 6.
Il me semble même que c’est un peu la raison d’être de Rust :
Graydon Hoare, créateur de Rust
https://www.infoq.com/news/2012/08/Interview-Rust/
Il voulait reprendre des idées existantes ailleurs sur des bases plus robustes par défaut. Ce qui change beaucoup de choses.
# C'est la 1er fois que je voie ça
Posté par uso (site web personnel) . Évalué à 4.
Autans ça fait depuis que j'ai commencer le dev, que je voie des gents dire qu'il faut arrêter le C, car tout les 5,6ans y’a une faille de sécurité majeur qui ne pourrais pas arrivé dans un langage qui n'a rien de "unsafe" comme Rust.
A chaque nouvelle fonctionnalité de C++, on entend des gents dire d’arrêter le C, à un tel point que ça ma fait pas aimer le C++, alors que j'aimais bien le langage.
mais c'est l'une des 1er fois que je voie quelqu'un mettre C et C++ dans le même panier. (alors que bon le C++11 et les suivant sont quand même assez safe(au moins autant que GNU C + static analyse)).
Bon bah les dev C++, bienvenue au club des gents qui utilise un langage non grata !
[^] # Re: C'est la 1er fois que je voie ça
Posté par BAud (site web personnel) . Évalué à 4.
faut passer à Ada :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.