• # Je change

    Posté par  (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  (site web personnel) . É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  (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  . É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  (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  . Évalué à 10.

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

  • # La fin de la "stabilite" des standards ?

    Posté par  (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  (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  (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  (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  (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

          • [^] # Re: La fin de la "stabilite" des standards ?

            Posté par  (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  (site web personnel) . Évalué à 2.

              projets orienté performance

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

                • [^] # Re: La fin de la "stabilite" des standards ?

                  Posté par  . É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::map au comportement si différent des autres langages.

                  Peut-être que j'ai été trop drogué au HashMap de Java et de Perl ?

                • [^] # Re: La fin de la "stabilite" des standards ?

                  Posté par  . É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  (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  (site web personnel, Mastodon) . Évalué à 3.

            une partie de la place qui était occupée il y a 20 ou 30 ans par C ou C++

            Et par Perl, qui semble tomber dans les oubliettes depuis quelques années…

          • [^] # Re: La fin de la "stabilite" des standards ?

            Posté par  (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).

            • [^] # Re: La fin de la "stabilite" des standards ?

              Posté par  (site web personnel) . Évalué à 3.

              je verrai ce que je ferai quand je prendrai ma retraite

              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  (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  (site web personnel) . Évalué à 7.

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

      https://link-society.com - https://kubirds.com

      • [^] # Re: Est-ce que c'est pas un peu tôt?

        Posté par  (site web personnel) . Évalué à 2.

        Rust n'est pas un langage "general purpose".

        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  . É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  (site web personnel, Mastodon) . Évalué à 4.

      C’est pas tôt, c’est vendredi :-)

  • # Le C a vécu 50 années, et vivra 50 de plus

    Posté par  (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

    • [^] # Re: Le C a vécu 50 années, et vivra 50 de plus

      Posté par  (Mastodon) . Évalué à 8. Dernière modification le 23 septembre 2022 à 15:45.

      Bref, merci de la leçon de morale, j'aurais pu m'en passer.

      Je ne crois pas qu'il y ait de leçon de morale.

      On parle d'une recomendation d'une entreprise.

      Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

      • [^] # Re: Le C a vécu 50 années, et vivra 50 de plus

        Posté par  . É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  . É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 ?

      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.

      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  (site web personnel) . Évalué à 5.

        pourquoi est-ce que ces solutions ne sont pas incluses dans gcc ou clang 

        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  . É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  (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  (site web personnel, Mastodon) . Évalué à 4.

        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)

        • [^] # Re: Le C a vécu 50 années, et vivra 50 de plus

          Posté par  . É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  . Évalué à 6.

      Vous savez que Rust n'a rien inventé ?

      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.

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

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.