Journal Appel à contribution pour un nouveau langage !

Posté par  . Licence CC By‑SA.
Étiquettes :
20
24
mar.
2021

Drew Devault 1 a annoncé le développement d'un nouveau langage "système".

Il vient de lancer un appel à contribution pour enrichir la bibliothèque standard du futur langage.

Dans son billet de blog, il décrit un langage "qui convient presque partout où le C est utile". Le but est d'avoir un langage petit (60 pages de spécifications), libéré de POSIX, avec quelques ingrédients des langages dit "modernes" (memory safe, unicode de base, …) et compatible avec l'ABI du C.

Le traditionnel Hello World(s) donne :

use io;

export fn main() void = {
    const greetings = [
        "Hello, world!",
        "¡Hola Mundo!",
        "Γειά σου Κόσμε!",
        "Привет мир!",
        "こんにちは世界！",
    ];
    for (let i = 0z; i < len(greetings); i += 1) {
        io::println(greetings[i]);
    };
};

L'objectif est d'avoir une version du langage finie et prête pour la production début 2022. Et que le compilateur supporte Linux, BSDs, Haiku et Plan 9; sur les architectures x86_64, aarch64, i686, riscv64, riscv32 et ppc64. Rien que ça.

Le langage n'a pas encore été baptisé mais a reçu le petit nom de BTR (Better Than Rust) sur la mailing list, ce qui en fera rire certains ici :)

Ambitieux et dans un secteur déjà bien occupé, on verra ce que ça donne !

  1. notamment développeur de Source Hut, fondateur de Sway et contributeur Alpine Linux ↩

  • # On m'avait dit que c'était impossible alors il l'a fait

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

    https://linuxfr.org/users/milo/liens/linux-et-la-securite-tel-un-desert-et-un-oasis#comment-1841388

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: On m'avait dit que c'était impossible alors il l'a fait

      Posté par  . Évalué à 4.

      Je ne crois pas que ce langage ait l’ambition d’être memory safe comme Rust.

      • [^] # Re: On m'avait dit que c'était impossible alors il l'a fait

        Posté par  (site web personnel) . Évalué à 5. Dernière modification le 24 mars 2021 à 22:49.

        Memory safe array, slice, and pointer types (and unsafe versions, if needed)

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: On m'avait dit que c'était impossible alors il l'a fait

          Posté par  . Évalué à 5. Dernière modification le 24 mars 2021 à 23:14.

          Il faut voir ce que ça recouvre en pratique. Le borrow checker de Rust est assez compliqué, et j’ai du mal à le voir rentrer dans le scope d’un langage qui se veut aussi simple. S’ils implémentent l’équivalent de std::unique_ptr + move semantics de C++, ça rentre tout à fait dans la case "memory safe pointer type", mais ça ne rentre pas du tout dans la case "memory safe comme Rust".

          • [^] # Re: On m'avait dit que c'était impossible alors il l'a fait

            Posté par  (site web personnel) . Évalué à 3. Dernière modification le 25 mars 2021 à 09:21.

            C'est quoi la différence?

            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

            • [^] # Re: On m'avait dit que c'était impossible alors il l'a fait

              Posté par  . Évalué à 4.

              C’est répondu dans ce fil : https://stackoverflow.com/questions/30011603/how-to-enable-rust-ownership-paradigm-in-c

              La différence c’est que Rust offre des garanties à la compilation que C++ est incapable d’obtenir, le compilateur raisonne à partir des contraintes imposées par le langage et ne laissera passer aucune erreur potentielle. Ça va plus loin en terme de sûreté.

            • [^] # Re: On m'avait dit que c'était impossible alors il l'a fait

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

              Je vais juste donner un exemple

              std::string insert_foo_at_index_and_return_previous(std::vector<std::string> &list, int index) {
    //OK, std::vector::operator[] throws if out of range
    std::string &old = list[index]; 
    list.insert(index, "foo");
    // BUG! insert modifie le vecteur et rends les références invalides: crash probable
    return old;
}

              Rust ne permet pas de faire cette faute car il n'autoriserait pas la référente old d'être valide après un appel vers une fonction non-const du vecteur qui est "emprunté".

              Là c'est juste un exemple, mais il y a plein de cas d'erreur qui ne sont pas possible en Rust sans éviter unsafe. Et cela peut devenir assez compliqué. Un autre exemple est la variance: https://doc.rust-lang.org/nomicon/subtyping.html : Le compilateur se charge de s'assurer qu'aucune erreur n'est commise et si tu fait une erreur, le compilateur te le fait savoir. (En pratique, on n'a pas besoin de comprendre cette page sauf si on veux faire code unsafe avec une interface safe.)

              • [^] # Re: On m'avait dit que c'était impossible alors il l'a fait

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

                Pour le coup tu n'utilises pas les smart pointers dans ton exemple, mais les dumb references de C++ :-)

                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                • [^] # Re: On m'avait dit que c'était impossible alors il l'a fait

                  Posté par  (site web personnel) . Évalué à 5. Dernière modification le 25 mars 2021 à 15:22.

                  std::vector est en quelque sorte un smart pointer, et il me semble que les référence ne sont pas considéré comme "dumb", même en C++ moderne.

                  Mais bon, voici un autre exemple un peu plus compliqué avec que des smart pointers

                  struct Foo {
   std::unique_ptr<struct Bar> child;
};

struct Bar {
   std::string name;
   void make_a_brother(std::shared_ptr<Foo> some_foo) {
      some_foo->child = std::make_unique<Bar>(Bar{"brother of " + name});
      // Oups, la ligne précédente peut faire un `delete this` si `some_foo->child == this`      
      std::cout << name << " now has a brother" << std::endl;
   }
};

int main() { 
   auto foo = std::make_shared<Foo>();
   foo->child = std::make_unique<Bar>(Bar{"John"});
   foo->child->make_a_brother(foo);
}

                  Le programme équivalent en Rust compile, mais panic au runtime (panicked at 'already borrowed: BorrowMutError', src/main.rs:14) au lieu de faire un use-after-free https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=36583330f87a2f66538290661916da2d

                  Edit: Note: le programme en Rust n'est pas très idiomatique car on utiliserait probablement plutôt des référence mutable à la place de Rc<RefCell> mais je voulais juste faire une traduction 1:1 du code en C++ (qui lui même est un peu bizarre à cause de la contrainte de ne pas pouvoir utilisé de pointeur ou références)

  • # let's go…

    Posté par  (site web personnel, Mastodon) . Évalué à 6.

    Qui est petit (lexique et spécification) ;
    Qui convient presque partout où le C l'est ;
    Qui est compatible avec l'ABI de C ;
    Qui compile sur les architectures x86_64, aarch64, i686, riscv64, riscv32, ppc64 ;
    Qui supporte Linux, BSDs, Haiku, Plan 9, MacOS X, Windows ;
    Qui a quelques ingrédients modernes (Unicode, coroutines) ;
    Bref, j'ai presque l'impression d'entendre parler de Go

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: let's go…

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

      Qui est petit (lexique et spécification) ;

      Pour moi cet objectif est contre-productif.
      Évidemment ça rends l'implémentation du compilateur plus facile. Mais qu'en est il de l'utilisation ?
      La complexité se déplace du compilateur, vers les programmes eux même.

      Le langage lui même est peut être plus facile à apprendre, mais le temps gagné à (ne pas) apprendre le language va être perdu sur le long terme en temps de développement.

      Les langages plus complets permettent de construire des couches d'abstraction qui simplifie la création de programme. Ce qui évite le programmeur de devoir faire du micro-management sujet aux erreurs.

      Dans un language plus « simple », chaque projet doit aussi ré-inventé la roue quand il faut faire quelque chose qui n'est pas prévu de base. Au final chaque projet a ses propres conventions qu'il faut ré-apprendre.

      Example extrême: le langage brainfuck est extrêmement simple (lexique et spec): sa spécification tient en une page. Mais ça rends l'écriture de programmes dans se langage très compliqué.

      • [^] # Re: let's go…

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

        Oui et non…

        Le but du C était quand même de rester assez proche de la machine, d'où en effet l'absence de couches d'abstractions supplémentaires ; mais on a un truc bien plus haut niveau que du pur assembleur (donc plus portable) et tout aussi proche (ce qui est nécessaire puisqu'il s'agit de programmation système.) On est dans un cas où on doit faire du micro-management (les besoins et contraintes d'un système d'exploitation à l'autre ou d'un pilote à l'autre ne pouvant ps vraiment se factoriser …mais les bibliothèques standard couvrent quand même les cas les plus courants constatés)

        Le but de bf est lui, par contre, d'avoir un langage d'assembleur (il en existe d'autres génériques) mais mais pour une Machine de Turing dans sa forme de base (générique/générale)

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: let's go…

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

          Le but du C était quand même de rester assez proche de la machine

          Même si les constructions du langage se convertissement facilement en langage machine, pour le reste il me semble que c'est une fausse affirmation, une croyance de la "jeune" (ayant débuté dans les année 80~90) génération de développeurs.

          Le C a apporté des concepts très haut niveau à l'époque où il été créé comparé à ce qui existait à l'époque, et c'est ça qui a fait tout son succès. C'est d'ailleurs ce qui le rend portable.

          Après j'ai pas envie de lancer un débat sur le C, et je ne pense pas que ton commentaire était fanatique ou autre, il est même plutôt pertinent.

          mais on a un truc bien plus haut niveau que du pur assembleur (donc plus portable) et tout aussi proche (ce qui est nécessaire puisqu'il s'agit de programmation système.)

          Par contre sur cette affirmation, je suis vraiment sceptique, avec les compilateurs modernes le code que tu écris en C n'a plus vraiment rien à voir avec ce qui généré à la fin.

          • [^] # Re: let's go…

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

            Pas de fanatisme dans mon commentaire :-) et je suis de la jeune génération (je m'y suis mis au début des années 90, et je n'ai pas connu les développements historiques de ces trucs nés un peu avant moi) Cependant, je m'intéresse beaucoup à l'histoire et l'évolution des technos&techniques que j'utilise mais je peux avoir mal compris.
            Je sais que le langage C a apporté beaucoup de concepts très hauts niveaux, mais j'ai vu aussi que quasiment tous ces concepts étaient déjà présents (et d'autres plus avancés) et que K&R ont justement retenu des choses qui leur permettaient de rester assez proche de la machine (et donc de pouvoir facilement et rapidement porter le compilateur) …et c'était le sens de mon commentaire. Ça se sent dans le types de base par exemple : y avait que du int dans la première monture (i.e. short et long ont été ajouté par la suite et alignés sur des multiples de 8, dans la continuité de char) ; et ce int est bien l'entier (plus précisément le word comme on pouvait lire dans certaines littératures de l'époque) de l'architecture cible (taille de registre qui n'est pas pareil sur les Intel/AMD x86 que j'ai connu et les PDP de la première heure…) Dans un des papiers (je ne sais plus si c'est de Denis ou un autre collaborateur du Lab) que j'ai lu, c'était à dessein que les constructions du langage devait pouvoir se traduire quasi directement en langage machine et qu'il n'y avait pas de vérifications faites par le compilo (car c'est ce qui pouvait rendre ceux existant plus long à porter et donnait aussi de moins bonnes performances quand on a tenté d'écrire des systèmes d'exploitation avec : il fallait donc pouvoir continuer à gérer les choses comme en assembleur tout en pouvant utilisant le genre de syntaxe qui commençait à voir le jour ; D'ailleurs, le système Unix n'est pas le premier a avoir été écrit dans un langage de haut niveau…)

            Je suis bien d'accord que le code généré par les compilateurs C est bien loin d'une traduction directe en assembleur. Ne serait-ce parce-que depuis longtemps il y a des paquets d'optimisations incroyables.

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: let's go…

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

          Le C++ et le Rust offre des couches d'abstractions sans compromettre "les besoins et contraintes d'un système d'exploitation ou d'un pilote"

          Le but du C était quand même de rester assez proche de la machine […] Le but de bf est lui, par contre, d'avoir un langage d'assembleur […] mais pour une Machine de Turing […]

          Je ne pense pas que ce soit vrai¹, mais peu importe.
          Le but du langage importe peut pour mon argument, ce que je voulais dire c'est que un langage simple ne veux pas dire que la programmation dans ce langage est plus simple. Par exemple je préfère programmer en C++ que en C car même si le C++ est plus long à apprendre, il est plus facile de faire des trucs pratiques en C++ qu'en C.

          (¹. À la fois le C et le BF ciblent une machine abstraite. (Par exemple le C suppose une stack de taille infinie, tout comme BF ne met pas de limite sur la taille de la mémoire, mais en pratique il y a des limites))

          • [^] # Re: let's go…

            Posté par  (site web personnel, Mastodon) . Évalué à 1.

            Ah oui, on est d'accord (+1) que plus c'est simple et plus c'est frustre pour des choses pratiques de nos jours.

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: let's go…

            Posté par  . Évalué à 5.

            Le but du langage importe peut pour mon argument, ce que je voulais dire c'est que un langage simple ne veux pas dire que la programmation dans ce langage est plus simple.

            Non, mais il y a bien quelques avantages à la simplicité qui concernent la programmation et pas que le compilateur :

            • Courbe d'apprentissage plus réduite (avantage à court terme).
            • Charge cognitive plus faible : mon cache interne est moins souvent saturé.

            Pour le premier point, je pense que tu seras d'accord avec moi. Pour le deuxième, c'est plus personnel, c'est une question de compromis qui dépend de chaque personne : pas assez d'abstraction et une syntaxe trop simples conduisent à plus de charge cognitive, mais trop d'abstraction et une syntaxe trop riche aussi. Il n'y a pas de limite universelle (du moins, je ne le pense pas), bien qu'il doit y avoir une tranche qui correspond aux limites d'une majorité d'êtres humains.

            Mon expérience personnelle, c'est qu'avec Go je ressens moins de charge cognitive qu'avec d'autres langages plus riches que je connais. Donc je suis plus productif avec globalement (en général, pas toujours), même si parfois cette simplicité conduit à plus de code.

            • [^] # Re: let's go…

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

              Je pense que tu fait une bonne analyse.

              Je travail en général sur des base de code assez grande, maintenue par plusieurs personnes sur de nombreuses années.

              Le code est écrit une fois, mais doit être lu et relu de nombreuses fois lors du débogage ou des améliorations.

              Alors comme tu dit, la simplicité du langage conduit à plus de code. Ça veux aussi dire plus de code à maintenir, lire, déboguer, refactoré. Ça veux dire aussi plus de possibilité d'erreurs, et une charge cognitive plus importante (cache interne plus souvent saturé)

              Car oui, un langage simple diminue la charge cognitive pour l'utilisation du langage, mais déplace cette charge cognitive sur le programme en lui même. Et je pense que c'est pire car avec de la pratique, le langage et les couche d'abstractions principales reste dans le cache interne, alors que le code lui même va et vient dans le cache en fonction de la partie du code que l'on touche.

              • [^] # Re: let's go…

                Posté par  . Évalué à 5.

                Je pense qu'on est d'accord, mais qu'on ne met pas la limite au même endroit.

                Par exemple, je considère le C comme étant un langage où le manque d'abstraction rend souvent le code plus difficile à lire : une partie de notre mémoire est utilisé pour se souvenir du rôle de chaque pointeur ou variable d'itération (abstraction dans notre tête à la volée), une autre pour vérifier qu'il n'y a pas d'erreurs de typage (conversions implicites etc.), une autre pour vérifier certaines propriétés (qu'on a pas oublié de free, qu'on n'a pas fait de double free, qu'on a pas fait d'erreurs d'indices, etc.). Au final ça fait beaucoup de choses auxquelles il faut être attentif en plus du cœur de l'idée.

                D'un autre côté, je considère par exemple Rust un peu dans l'autre extrême : trop de concepts (mutation vs immutabilité, temps de vie explicites, macros vs fonctions, généricité un peu partout, itérateurs vs boucles, différents types de chaînes de caractères, etc.) se disputent mon cache (mémoire de travail), ce qui me freine dans ma lecture et ma compréhension.

                Plus on devient adepte du langage, plus les considérations annexes deviennent des réflexes et donc prennent moins de place dans notre mémoire de travail. Mais à un moment on arrive quand même à notre limite, ou du moins notre vitesse de progression devient très lente.

                • [^] # Re: let's go…

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

                  Exactement.

                  Cela dit, puisque tu parles de Rust, que je connais, je vais un peu détaillé les concepts.
                  La plupart des concepts n'ont pas besoin d'être dans le "cache interne" car le compilateur garde ces concepts pour toi et te rappelle quand tu fais une erreur.

                  mutation vs immutabilité

                  Ce concept permet en fait de libérer de la charge cognitive, car tu sait que quand une variable n'est pas mutable, elle ne change pas. Si tu connais la valeur de la variable au début de la fonction, tu n'a pas besoin de mettre tout le code de la fonction dans ta mémoire de travail pour savoir que la valeur de cette variable n'a pas changer

                  temps de vie explicites

                  En pratique, il y a assez peu de temps de vie explicites. Et encore une fois, quand c'est nécessaire, ça permet de faciliter le raisonnement sur la validité des objets que tu dois déduire toi même dans d'autre langages qui n'ont pas se concept.

                  généricité un peu partout

                  En effet, la généricité peut être parfois difficile à comprendre. Mais c'est aussi ce qui permet aux bibliothèques de créé des interface plus ou moins intuitive qui viennent là encore simplifier le code les utilisant.

                  itérateurs vs boucles

                  Qui permettent là encore de choisir de faire du code lisible et concis.

                  • [^] # Re: let's go…

                    Posté par  . Évalué à 2.

                    La plupart des concepts n'ont pas besoin d'être dans le "cache interne" car le compilateur garde ces concepts pour toi et te rappelle quand tu fais une erreur.

                    Une annotation visuelle dans le code passe à un moment par notre mémoire de travail, même si c'est un temps bref et qu'on la laisse vite de côté. Du coup, une telle annotation visuelle n'allège la mémoire de travail que si l'information qu'elle apporte nous était nécessaire sur le moment pour comprendre le code, par exemple en nous évitant d'avoir à établir des invariants dans notre tête. Par contre, si sur le moment l'info n'est pas utile pour ce qu'on veut comprendre, au contraire, elle nous distrait.

                    Ce concept permet en fait de libérer de la charge cognitive, car tu sait que quand une variable n'est pas mutable, elle ne change pas. Si tu connais la valeur de la variable au début de la fonction, tu n'a pas besoin de mettre tout le code de la fonction dans ta mémoire de travail pour savoir que la valeur de cette variable n'a pas changer

                    En effet, sauf que souvent le fait qu'une variable aille être utilisée de façon mutable ou non s'intuite du fait d'autres informations déjà analysées, comme le nom ou type de la variable ou le nom des fonctions qui l'utilisent. Du coup, souvent, une annotation de mutabilité ou non dans le code représente juste un bit d'information redondant, utile pour le compilateur mais pas forcément pour le développeur. Une information redondante risque de saturer la mémoire de travail.

                    Cela dit, le cas de la mutabilité ou non mutabilité est assez secondaire (un bit d'information, c'est peu de place), par rapport à d'autres choses comme la généricité (où analyser l'information additionnelle relative à la couche d'abstraction est nécessaire pour comprendre le code, ce n'est pas juste une information annexe).

                    En pratique, il y a assez peu de temps de vie explicites. Et encore une fois, quand c'est nécessaire, ça permet de faciliter le raisonnement sur la validité des objets que tu dois déduire toi même dans d'autre langages qui n'ont pas se concept.

                    Tout à fait : si c'est notre objectif de lecture du moment, les annotations vont nous éviter de remplir la mémoire de travail avec des raisonnements garantis par le compilateur. Mais seulement si ce qui nous intéresse sur le moment a un lien avec ces garanties.

                    Au final, je trouve pas qu'il soit facile de toujours trancher sur l'utilité relative de certaines fonctionnalités. Il faudrait pour cela des études statistiques pas évidentes à mettre en place.

                    Un autre exemple parlant est celui des bibliothèques standard : dans certains langages, elles essaient d'être plutôt minimales et ne pas ajouter de fonctions qui se déduisent facilement des autres. Dans d'autres langages, la barrière d'entrée pour de nouvelles fonctions est moins importante.

                    Trop peu de fonctions a tendance à distraire le développeur, car il doit souvent réécrire des petites fonctions à l'aide de celles qu'il connait. Trop de fonctions a tendance à distraire aussi le développeur, car il hésite entre réécrire ou bien chercher la bonne fonction dans la documentation ; or, celle-ci étant plus longue et contenant plus de fonctions secondaires, elle demande plus d'efforts à notre mémoire de travail lors du parcours : l'essentiel est moins immédiatement visible.

      • [^] # Re: let's go…

        Posté par  . Évalué à 2.

        Dans un language plus « simple », chaque projet doit aussi ré-inventé la roue quand il faut faire quelque chose qui n'est pas prévu de base. Au final chaque projet a ses propres conventions qu'il faut ré-apprendre.

        Donc cela veut dire que si tu veux qu'un langage "simple" perce, il te faut une grosse communauté qui fera des libs et frameworks qui seront considérés comme "standards".

  • # Mot clef offensant

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

    Il faudrait utiliser fun pour les fonctions, fn ça me fait de le peine.

    Et pour main, je trouve ça bizarre. Pourquoi pas pied ou oreille ? Il faudrait un terme plus clair pour désigner la fonction qui donne du travail aux autres. Peut être master?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Mot clef offensant

      Posté par  . Évalué à 3.

      Il faudrait un terme plus clair pour désigner la fonction qui donne du travail aux autres. Peut être master?

      Vu que c'est la porte d'entrée du programme, je pense que je l’appellerais door dans mon futur fork de ce futur langage.

      • [^] # Re: Mot clef offensant

        Posté par  . Évalué à 8.

        Ou windows si on aime entrer par la fenêtre

        • [^] # Re: Mot clef offensant

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

          On pourrait ainsi avoir des programmes mixtes :

          • si on le lance dans un terminal texte, c'est la méthode door() qui est appelé ;
          • si c'est depuis dans un bureau graphique, c'est window() ;
          • s'il tourne via un serveur vocal, c'est speaker() ;
          • dans un jouet sexuel connecté, c'est finger().

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Je dois être un nazi de la syntaxe C ...

    Posté par  . Évalué à 6.

    Pour moi tout ce qui s'écarte de la syntaxe C c'est horrible (ce jeux de mots de grand maitre ! :)). J'y arrive pas. C'est mon principal problème avec rust.

    Du coup je comprends pas pourquoi les gens vont vers d'autre syntaxe que le C. Une autre syntaxe c'est un peu comme une autre langue qu'il faut apprendre. Je sais qu'il y a des ambiguité dans la grammaire C mais il est possible de les régler sans presque rien changer a la syntaxe.

  • # J'ai 14 langages...

    Posté par  . Évalué à 10.

    Standards

    • [^] # Re: J'ai 14 langages...

      Posté par  . Évalué à -10.

      XKCD, c'est rigolo, mais la ça n'a aucun rapport.

      • [^] # Re: J'ai 14 langages...

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 26 mars 2021 à 17:16.

        Ils n'annoncent pas qu'ils veulent tout remplacer mais ils laissent quand même penser qu'il y a une place libre à un endroit où j'ai pourtant l'impression qu'il y a un paquet de langages qui se positionnent. Donc je trouve que c'est plutôt approprié.

  • # Et par rapport à Zig ?

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

    C'est étrange, j'ai l'impression que c'est quasiment le même positionnement que Zig. Quelqu'un saurait dire la différence ?

    More robust error handling via tagged unions

    L'opérateur ! permet de créer des unions avec des erreurs dans ce but : https://ziglang.org/documentation/master/#Error-Union-Type.

    Improved, Unicode-aware string support

    Zig considère l'UTF-8 comme l'encodage par défaut des chaînes de caractères : https://ziglang.org/documentation/master/#String-Literals-and-Unicode-Code-Point-Literals

    Memory safe array, slice, and pointer types (and unsafe versions, if needed)

    Zig a des « sentinel-terminated pointers » (et de même pour les tableaux et slices) : https://ziglang.org/documentation/master/#Sentinel-Terminated-Pointers

    Direct compatibility with the C ABI for trivial C interop

    C'est un des gros points forts de Zig : https://ziglang.org/learn/overview/#integration-with-c-libraries-without-ffibindings

    A simpler, context-free, expression-oriented syntax

    La grammaire de Zig m'a l'air de répondre à ça : https://ziglang.org/documentation/master/#Grammar

    A standard library free of the constraints of POSIX or the C standard

    J'ai du mal à dire. La bibliothèque standard de Zig est là : https://ziglang.org/documentation/master/std/

    L'objectif est d'avoir une version du langage finie et prête pour la production début 2022. Et que le compilateur supporte Linux, BSDs, Haiku et Plan 9; sur les architectures x86_64, aarch64, i686, riscv64, riscv32 et ppc64. Rien que ça.

    Zig est en train de réécrire son compilateur en zig (avec ce qu'il faut pour bootstraper correctement le compilateur), donc ce n'est clairement pas encore prêt pour de la production. Mais ça paraît bien plus avancé que ce nouveau langage.

    Côté plateforme, il doit manquer Plan 9 (https://github.com/ziglang/zig/issues/7153) et la prise en charge d'Haiku a l'air toute récente (https://github.com/ziglang/zig/pull/7546).

    Pour les architectures :
    https://ziglang.org/learn/overview/#wide-range-of-targets-supported (comme ça s'appuie sur LLVM, il y a déjà un paquet d'architectures prises en charge).

    • [^] # Re: Et par rapport à Rust ?

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

      More robust error handling via tagged unions

      Les enum de rust sont des tagged unions et utilisé pour la gestion des erreurs.

      Improved, Unicode-aware string support

      Rust considère que le type str et String contiens de l'UTF-8

      Memory safe array, slice, and pointer types (and unsafe versions, if needed)

      Exactement ce que Rust a.

      Direct compatibility with the C ABI for trivial C interop

      C'est possible en rust grâce à #[repr(C)] et extern "C" fn et on peut généré des définition rust à partir d'en-tête C.

      A simpler, context-free, expression-oriented syntax

      Ça dépends "simpler" par rapport à quoi. Rust est quasiment context-free, à l'exception des raw string literal. Mais rust est expression-oriented.

      A standard library free of the constraints of POSIX or the C standard

      Comme rust.

      objectif est d'avoir une version du langage finie et prête pour la production début 2022. Et que le compilateur supporte Linux, BSDs, Haiku et Plan 9; sur les architectures x86_64, aarch64, i686, riscv64, riscv32 et ppc64. Rien que ça.

      Rust est déjà fini et stable depuis 2015, et supporte plein d'architectures (merci LLVM)
      (J'ai pas trouvé si rust supporte Plan 9)

      • [^] # Re: Et par rapport à Rust ?

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

        Ça dépends "simpler" par rapport à quoi

        Je suppose que c'était en comparaison du C. Mais, à part C++, j'ai du mal à voir quel point de comparaison mettrait Rust dans la catégorie "simpler". La grammaire de Rust est connue pour être riche et les efforts pour la documenter n'ont pas été très concluants jusque là (cf https://github.com/rust-lang/rfcs/blob/master/text/1331-grammar-is-canonical.md et https://github.com/rust-lang/wg-grammar par exemple).

        Globalement, je vois bien pourquoi une personne peut vouloir créer un "better C" qui ne soit pas Rust. Rust est très complexe, non standardisé, et demande beaucoup d'efforts pour être appris. Il convient bien pour des projets complexes (genre des briques d'un navigateur web), mais il y a probablement une place pour un autre langage pour des projets plus simples et qui n'ont pas besoin de toute cette complexité.

      • [^] # Re: Et par rapport à Rust ?

        Posté par  . Évalué à 2.

        Vu son billet, il ne cherche pas la comparaison avec rust mais juste avec le C. Après, il me semble inutile de faire la liste de ce que rust ou go ont déjà car :

        • Ce nouveau langage reste quand même très flou jusqu'à présent :)
        • C'est un furieux du minimalisme qui n'aime pas rust (je pense que la blague du nom est plutôt liée à ça qu'à une envie de concurrencer rust… c'est "better" dans la vision d'une partie des utilisateurs de source hut). Donc, les arguments que rust possède déjà les fonctionnalités qu'il veut, et bien je crois qu'il s'en fout :)
        • Il a déjà plusieurs projets en Go et il a l'air d'aimer

        En passant, merci pour tes réactions (et aux autres aussi hein ). Je ne suis pas trop branché langage systèmes/"simples" et vous m'aidez à me faire mon éducation ;)

    • [^] # Re: Et par rapport à Zig ?

      Posté par  . Évalué à 3.

      La question, qui semble à mes yeux très pertinente, est évoquée sur le (petit) fil de discussion chez HackerNews: https://news.ycombinator.com/item?id=26515853 . Malheureusement, s'il y a des éléments de réponse (l'intérêt de Drew pour Zig), la discussion n'a pas duré assez longtemps avec plus de monde pour y répondre de manière claire. :-(
      Je me serais attendu à plus d'échanges sur ce forum, compte tenu du sujet et du personnage de Drew…

    • [^] # Re: Et par rapport à Zig ?

      Posté par  . Évalué à 2.

      La comparaison avec Zig a été levée (mais pas en aussi détaillée que toi ) sur la mailing list.

      Morceau choisi :

      May I ask how your new systems programming language differs from Zig?

      It's much simpler, and does not provide any metaprogramming facilities
      (such as comptime). Unlike Zig, BTR does not use LLVM.

      Zig takes about 30 minutes to compile and run its test suite, not
      including the time required to build LLVM, whereas BTR takes about 5
      seconds to build qbe[0], its compiler, and its stdlib, and run the
      compiler and stdlib test suites.

      Après ce futur langage reste très mystérieux. Faudra voir dans 1 an :)

      • [^] # Re: Et par rapport à Zig ?

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        Mouais… il répond avec des benchs qu'on demande à voir ; et si ce n'est que ça son souci, je suis sûr que ça va s'améliorer de l'autre côté.
        Et la bonne blague de pointer comptime et LLVM comme des points faibles à l'heure actuelle.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: Et par rapport à Zig ?

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

          Le temps de compilation de mon compilateur, en tant qu'utilisateur du langage je m'en fous un peu[1]. C'est léger comme argument.

          [1] c'est important, mais pas pour l'utilisateur. C'est pas ça qui va faire adopter un langage.

          • [^] # Re: Et par rapport à Zig ?

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

            J'ai arrêté le C++ à cause de ça. C'est sympa de mouler pendant que ça compile de temps en temps, mais pas 42% d'une journée de travail.

            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

            • [^] # Re: Et par rapport à Zig ?

              Posté par  (site web personnel) . Évalué à 4. Dernière modification le 26 mars 2021 à 19:09.

              Il parle du temps de compilation du compilateur pas du temps de compilation de ton programme. Tu recompiles GCC plusieurs fois par jour ?

      • [^] # Re: Et par rapport à Zig ?

        Posté par  (Mastodon) . Évalué à 5.

        Je trouve que l'aspect meta-programmation de Zig est extrêmement bien pensé et s'intègre très bien dans le langage. Je vais garder mon paquet de Zig du coup parce que son machin a l'air de ressembler à un langage jouet avec lequel on ne pourra jamais rien faire de sérieux.

    • [^] # Re: Et par rapport à Zig ?

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

      Zig est très intéressant car il permet de développer rapidement et simplement des programmes performants. Rust est un excellent langage qui apporte beaucoup a l'informatique. Il existe aussi Nim qui a un certain intérêt. Go est très utile aussi mais plutôt dans un autre registre… Et beaucoup d'autres (bien de trop)…

      Pour moi ce nouveaux langage est plus un parasite qu'autre chose. Il n'apporte rien de nouveau.

      Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

      • [^] # Re: Et par rapport à Zig ?

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

        Pour moi ce nouveaux langage est plus un parasite qu'autre chose

        Parasite est un grand mot, je pense. Parasite de quoi?
        Je suis d'accord avec toi sur l'idée. Mais si les gens ont envie de s'amuser en créant un nouveau langage, pourquoi pas…?
        (oui, ça pourrait diviser les communautés, c'est vrai, mais on en est pas encore là)

  • # Pourquoi ?

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Il y a déjà une foultitude de langages informatiques, et j’ai un peu (beaucoup) de mal à comprendre pourquoi il y en a tant. Qu’est-ce qui justifie cette profusion de langages à part compliquer un peu tout ? Idem, soit dit en passant pour les syntaxes (html, markdown, etc.)

    Alors pourquoi créer un langage supplémentaire et ne pas améliorer, si cela s’avère nécessaire, un langage existant ?

    Je ne demande qu’à être convaincue (pas par des arguments du type « Rust c’est bon mangez-en » ou « les autres c’est nul, jetez-les »).

    Merci. Tout ça me plonge dans des abîmes de perplexité, je dois dire. Parce qu’en fait, à lire les commentaires, j’ai un peu l’impression qu’un nouveau langage n’apporterait pas grand chose de plus que des complications. Ou bien  ?

    « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

    • [^] # Re: Pourquoi ?

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

      • Tu ne fais pas un couteau-suisse 8347846378 d'outils. Générique / spécialisé, ou être bon dans certains domaines et être pas terrible ou carrément absent sur d'autres.
      • Le poids de l'historique : le langage a été fait à un moment donné, avec les connaissances de l'époque, et il faut rester plus ou moins rétrocompatible
      • Évolutions des connaissances : l'informatique a progressé dans les langages, mais les dernières nouveautés ne sont pas forcément dans les anciens langages, ou pas toutes, ou pas encore
      • Les goûts et les couleurs : la meilleure syntaxe c'est {camelcase,snakecase,spacecake,quesaisje} et il faut un garbage collector et ne pas en avoir, des points virgule en fin de ligne ou des espaces au début, être compilé et/ou interprété, multiplateforme, multiarchitecture, etc., etc.
      • Chacun veut le sien
      • Personne ne connaît tous les langages existants, donc on peut réinventer dans son coin.
      • La popularité ne dépend pas forcément du langage lui-même (mais de son écosystème, du marché du travail ou de la réputation, etc.)
      • La résistance au changement : le COBOL est forcément mieux que le Crystal, il s'est bonifié comme le bon fromage…
      • Il faut aussi accepter les échecs : oh un nouveau langage qui a l'air génial… bon finalement non
      • Tout le monde a son langage qui va révolutionner et devenir la norme et tout remplacer. C'est juste que ce n'est jamais le même…
      • …

      • [^] # Re: Pourquoi ?

        Posté par  . Évalué à 2.

        Un garbage collector

        Est-ce que ça fait vraiment partie de la définition du langage ?

        • [^] # Re: Pourquoi ?

          Posté par  . Évalué à 7.

          Est-ce que ça fait vraiment partie de la définition du langage ?

          Le modèle mémoire fait parti de la définition d'un langage. Le fait que certains langages aient un gc optionnel fait partie de ses fondements (alors que les langages où il existe une bibliothèque pour faire du gc est un peu différent - au même titre que tu peux implémenter un langage dans un autre -).

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Pourquoi ?

            Posté par  . Évalué à 2.

            C’est essentiel pour donner la sémantique des instructions. À la rigueur on pourrait dire « si on arrive à faire une implémentation qui fait la même chose sans gc avec exactement les mêmes lignes de codes, ça fait pas partie de la définition du langage » mais il y a des trucs qu’on fait avec qu’on doit par trop savoir faire sans.

    • [^] # Re: Pourquoi ?

      Posté par  . Évalué à 5. Dernière modification le 25 mars 2021 à 11:42.

      Je dirais qu'un nouveau langage peut se révéler pertinent s'il se révèle plus adapté que l'existant à certains cas d'usage.

      En tant que développeur, j'essaye d'utiliser les technos les plus adaptées à mon projet du moment. Par exemple, je ne suis pas très fan du développement front-end, mais je dois dire que React et Vue ont apporté beaucoup dans ce domaine. On parle pas mal en ce moment de Svelte, qui sans être un nouveau langage (c'est un transpileur pour des fichiers incluant du JavaScript, de l'HTML et du CSS), est à mon sens un (énorme) pas dans le bon sens, notamment avec SvelteKit.

      De la même façon, si je dois créer un système basé sur le CQRS et l'event-sourcing, je me dirigerais sans doute vers Elixir, parce que son modèle acteur s'adapte super bien à la notion d'agrégat.

      Pour moi, cette diversité me permet de ne pas avoir à me contenter d'un outil peut-être plus universel, mais moins adapté aux cas particuliers.

      Le truc, c'est que ces technologies, langages, frameworks, se nourrissent les uns des autres. Elm a apporté un pattern que tu retrouve dans React/Redux et Vue/Vuex. Les langages fonctionnels ont essaimé jusque dans Java, à partir de Java 8.

      Parfois, une technologie apparaît from scratch, en essayant soit d'apporter une vision, des patterns en rupture avec l'existant, soit au contraire en essayant d'être un syncrétisme de ce qui se fait de mieux.

      Sans ces tentatives, qui n'aboutissent pas toujours, je pense que l'évolution de nos outils serait bien plus lente. Donc, si l'utilité propre de nouveaux langages peut-être discutable, du point de vue de l'écosystème, le dynamisme apporté par ce foisonnement d'idées est à mon sens une raison largement suffisante :)

    • [^] # Re: Pourquoi ?

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

      Alors pourquoi créer un langage supplémentaire et ne pas améliorer, si cela s’avère nécessaire, un langage existant ?

      Pour moi, les vraies raisons sont essentiellement académiques : on veut par exemple explorer une autre approche ou mettre en œuvre de nouvelles théories (cf. programmation orientée objet, programmation fonctionnelle, etc ; naissance du Pascal ou du basic ; etc.)
      Le reste du temps, les reproches techniques peuvent se résoudre en améliorant les langages existants. Ça peut aboutir à un nouveau langage issu de l'autre (c'est le cas de C++ et ObjectiveC qui ajoutent l'objet au C traditionnel et tentent d'en corriger quelques autres aspects) ou de nouveaux compilateurs (cf. Clang pour le C) avec de nouveaux outils (cf. LLVM par exemple)

      Le reste du temps, comme ici, je pense que c'est le syndrome NIH (donc de gens qui ont la grosse tête et un trop gros égo et rêvent d'avoir leur nom associé à un langage comme génial/géniale inventeur/inventeuse…) Il est possible que ce soit aussi simplement par ignorance (on tente de alors de refaire quelque chose qui a été déjà fait ailleurs)
      Dans le cas présent, d'autres commentaires ont justement mentionné Zig et Go par exemple qui répondent déjà au cahier des charges…

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Pourquoi ?

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

      Pour les mêmes raisons qui fait qu'on crée de nouvelles voitures, de nouveaux vêtements, de nouvelles chansons…

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Pourquoi ?

      Posté par  (Mastodon) . Évalué à 5.

      Parce qu’en fait, à lire les commentaires, j’ai un peu l’impression qu’un nouveau langage n’apporterait pas grand chose de plus que des complications.

      Cela apporte de longs fils de commentaires sur LinuxFR. Ce n'est pas rien ! Ou bien tu places cela dans les complications ? ;-)

      Surtout, ne pas tout prendre au sérieux !

  • # Drew ? J'ai un peu du mal avec ce type

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 25 mars 2021 à 11:24.

    Je le connais un peu car il est parmi les anciens contributeurs de la distribution Alpine dont je suis aussi contributeur.

    Loin de moi l'idée de vouloir le dénigrer mais j'ai du mal avec sa façon de faire.

    Il réinvente la roue pour beaucoup de choses et nous les impose par après. Chez Alpine il a voulu mettre en place son système de mailing list assez mauvais (peu personnalisable et quelques problèmes) et a décidé de partir dès lors qu'on a dit qu'on l'utiliserait plus pour contribuer. Il n'aime pas les manpage alors il a écrit son propre format bien plus minimaliste et largement pas assez flexible pour écrire des pages de qualité. Devinez quoi, il l'a mis en place dans les pages de manuel du gestionnaire de paquet apk. Cela signifie qu'en tant que nouveau contributeur, au lieu de pouvoir contribuer à quelque chose que vous connaissez, vous devez apprendre un nouveau format pour une seule et unique personne à cause du syndrome NIH. Il a aussi des opinions personnelles assez fortes et vous empêches littéralement de faire autrement (essayez d'envoyer un mail HTML sur Alpine ou avec une petite pièce jointe, vous allez être renvoyé vers une de ces pages perso. Il n'aime pas nvidia (oui nvidia c'est mal), mais ce n'est pas non plus obligatoire de faire pression sur ceux qui en ont une. C'est vrai que les deux cas sont à proscrire sur une ML mais bon). Quelques recherches sur HN/Reddit vous en dira un peu plus à son sujet.

    Pour moi ce langage n'est qu'un énième syndrome NIH dont il est atteint alors comme il n'aime pas Rust, C++, Go ou autre langage moderne et ben… il en écrit un nouveau. Ainsi, ce dont j'ai à lui reprocher se répercutera sur son énième projet.

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: Drew ? J'ai un peu du mal avec ce type

      Posté par  . Évalué à 1.

      Merci pour ton regard intéressant. Cela ne m'étonne pas vraiment qu'il ait un côté My way or the Highway.

      Je ne le suis que de loin en loin et c'est vrai qu'il est assez radical (voir de plus en plus avec le temps ?). Par contre, j'avoue que je ne savais pas qu'il avait arrêté de contribuer à Alpine.

    • [^] # Re: Drew ? J'ai un peu du mal avec ce type

      Posté par  . Évalué à 10.

      Ça me rappelle ce ticket où j'échange avec un utilisateur :
      https://github.com/swaywm/sway/issues/939

      Il finit par arriver en plein milieu, dire n'importe quoi et il envoi chier l'utilisateur.
      L'utilisateur répond gentiment qu'il est à côté de la plaque.
      Il ferme le topic en disant à l'utilisateur qu'on est pas à sa merci.

      Du coup, ça a été mon dernier patch ^ Ça m'a refroidi !

      • [^] # Re: Drew ? J'ai un peu du mal avec ce type

        Posté par  . Évalué à 5.

        Et c’est pas le seul exemple, il fait ça régulièrement.

        Il arrive dans un débat, donne son avis comme si c’était le seul qui compte et prend tout le monde de haut comme s’il était le seul à connaître le sujet dont il parle.

        Un exemple récent c’est le passage à Rust pour une partie de pyca/cryptography où il vient expliquer à un des développeurs (qui ne lui a rien demander) qu’il est trop con pour savoir écrire du C.

        • [^] # Re: Drew ? J'ai un peu du mal avec ce type

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

          Il a complètement raison: une lib python qui soudain décide de dépendre d''un nouveau langage, c'est bien pourrave.

          Imagine qu'on rende obligatoire l'installation d'un openjdk pour utiliser Django :-)

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Drew ? J'ai un peu du mal avec ce type

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

            Autant j'aime pas Rust autant cette remarque n'as pas de sens. Il y a beaucoup de modules python qui sont natifs (donc codés en C, C++ ou Rust). Ce n'est pas nouveau et c'est nécessaire pour certaines API (OpenGL, Qt, etc).

            git is great because linus did it, mercurial is better because he didn't

            • [^] # Re: Drew ? J'ai un peu du mal avec ce type

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

              C/C++ est universel. Pas Rust.

              Dans 10 ou 20 ans, peut être que ça ne posera plus de problème, mais aujourd'hui…

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

              • [^] # Re: Drew ? J'ai un peu du mal avec ce type

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

                Mais est-ce vraiment nécessaire d'être universel ? (D'ailleurs C n'est pas « universel » non plus)
                L'argument est que Rust fonctionne sur les plateformes concernée, et le reste des plateformes sont tout simplement obsolètes ou n'ont de toute façon pas assez d'utilisateurs que pour que les mainteneurs se sentent obligés de supporter ces plateformes gratuitement.

                • [^] # Re: Drew ? J'ai un peu du mal avec ce type

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

                  Mais est-ce vraiment nécessaire d'être universel ?

                  Non vivement qu'ils droppent le support de linux en ajoutant une dépendance à Visual Basic.

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                  • [^] # Re: Drew ? J'ai un peu du mal avec ce type

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

                    Alors, mauvais exemple car Visual Basic tourne sur Linux :-)

                    Mais Linux est un des système majeur que python-cryptography supporte. Par contre, est-il vraiment nécessaire de supporter HPUX ou AIX ? D'ailleurs est-ce que c'était supporté avant le changement à Rust ?
                    La plupart des gens concerné par le changement ont en fait simplement besoin de rajouter apt-get install rust ou équivalent dans leur CI.

                    • [^] # Re: Drew ? J'ai un peu du mal avec ce type

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

                      La plupart des gens concerné par le changement ont en fait simplement besoin de rajouter apt-get install rust ou équivalent dans leur CI.

                      En tout cas ça ne donne pas envie de se mettre à Rust avec un tel état d'esprit :(

                      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                      • [^] # Re: Drew ? J'ai un peu du mal avec ce type

                        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 26 mars 2021 à 17:47.

                        En tout cas ça ne donne pas envie de se mettre à Rust avec un tel état d'esprit :(

                        Ce n'est pas "l'état d'esprit de Rust", c'est le choix des développeurs du module Python. On peut difficilement leur reprocher de faire évoluer leur projet comme ils l'entendent.

                        Certes ça emmerde des gens, mais est-ce que les responsables d'un projet doivent se plier à la volonté d'une partie (dans ce cas assez petite) de leurs utilisateurs ?

                        Si tu regardes Linux (qui a beaucoup plus de moyens soit dit en passant), lorsqu'ils parlent d'abandonner des architectures, il y'en a toujours pour se plaindre. Mais la résolution est toujours la même : si personne n'est assez intéressé par l'archi pour s'occuper de la maintenance, dommage pour vous.

                        • [^] # Re: Drew ? J'ai un peu du mal avec ce type

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

                          Certes ça emmerde des gens, mais est-ce que les responsables d'un projet doivent se plier à la volonté d'une partie (dans ce cas assez petite) de leurs utilisateurs ?

                          Rien ne les y oblige, mais c'est dommage de casser ce qui marche.

                          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                        • [^] # Re: Drew ? J'ai un peu du mal avec ce type

                          Posté par  . Évalué à 5.

                          Si tu regardes Linux (qui a beaucoup plus de moyens soit dit en passant), lorsqu'ils parlent d'abandonner des architectures, il y'en a toujours pour se plaindre. Mais la résolution est toujours la même : si personne n'est assez intéressé par l'archi pour s'occuper de la maintenance, dommage pour vous.

                          Non les gens ne se plaignent pas pour plusieurs raisons :

                          • ils abandonnent des archi vraiment très peu utilisées
                          • ils mûrissent leur abandons et c'est un choix et non un effet de bord d'une volonté autre

                          C'est très différents parce qu'ils peuvent te dire très précisément et posément pourquoi ils arrêtent. Ce n'est pas : "on a ajouté le support d'usb3 (du coup on abandonne ppc lol)". C'est tout le différence entre uun projet qui considère le support d'architecture comme un sujet à part entière ou comme un boulet qui le contraint.

                          Je ne suis pas ce que devrait faire les dev en question, mais c'est juste que le point sur le noyau c'est pas vraiment la même façon de faire. Et c'est logique qu'ils prennent le sujet avec autant de sérieux. Pour les bibliothèques python c'est juste une mise en lumière de ce qu'est et ce que n'est pas la portabilité de python.

                          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                    • [^] # Re: Drew ? J'ai un peu du mal avec ce type

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

                      La plupart des gens concerné par le changement ont en fait simplement besoin de rajouter apt-get install rust ou équivalent dans leur CI.

                      Non ce n'est pas si simple. Rust est bien moins portable que C et ne tourne pas sur toutes les architectures.

                      git is great because linus did it, mercurial is better because he didn't

                    • [^] # Re: Drew ? J'ai un peu du mal avec ce type

                      Posté par  . Évalué à 2.

                      Par contre, est-il vraiment nécessaire de supporter HPUX ou AIX ? D'ailleurs est-ce que c'était supporté avant le changement à Rust ?

                      Sous AIX, il n'était pas officiellement supporté, mais il marchait. Sous peu, il ne marchera plus. Donc tous les programmes qui dépendent de cryptography ne pourront plus marcher sous AIX jusqu'au portage de Rust.

                      • [^] # Re: Drew ? J'ai un peu du mal avec ce type

                        Posté par  . Évalué à 2.

                        AIX ne fait par partit des plateformes officiellement supportées par cryptography, et visiblement ne l’a jamais été.

                        J’ai regardé rapidement l’historique Git et j’ai pas vu de mention à AIX. J’ai vu des issues qui ont l’air d’avoir été fermé en « won’t fix » et une PR qui a l’air d’améliorrer le support pour cette plateforme.

                        À part ça, je vois personne que ça intéresse réellement.

                      • [^] # Re: Drew ? J'ai un peu du mal avec ce type

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

                        Déja, AIX ça-pue-c-est-pas-libre. Donc voilà, bien fait pour leur pomme à ceux qui utilise du prorio.

                        Et plus sérieusement, si il y a des gens vraiment intéressé par AIX, il est plus que probable que Rust soit aussi porté pour AIX. LLVM supporte déjà AIX et Rust supporte déjà l'architecture powerpc64 sous Linux. Donc ça dois pas être très compliqué d'étendre le support à AIX, il ne doit plus manquer beaucoup de pièce au puzzle. Si le fait que python-cryptography accélère le développement de Rust pour AIX, c'est une bonne chose.

                        • [^] # Re: Drew ? J'ai un peu du mal avec ce type

                          Posté par  . Évalué à 2.

                          LLVM supporte déjà AIX et Rust supporte déjà l'architecture powerpc64 sous Linux. Donc ça dois pas être très compliqué d'étendre le support à AIX, il ne doit plus manquer beaucoup de pièce au puzzle.

                          En fait, si, c'est compliqué. Le support de LLVM pour AIX est encore très partiel. En gros, ce qui sert pour Clang. Et malheureusement, le sous-ensemble pour Clang et celui pour Rust sont en parti différent. Certaines choses sont contournables, d'autres doivent être implémentées dans LLVM, et ce n'est pas toujours facile, car AIX a parfois sa façon de faire propre et très différentes des autres Unix.

          • [^] # Re: Drew ? J'ai un peu du mal avec ce type

            Posté par  . Évalué à 8.

            Il a complètement raison

            De débarquer comme un connard pour emmerder et insulter des gens qui ne lui ont rien demandé ?

            Regarde sa réponse dans swaywm/sway#939 : « Remember this project is run by volunteers who owe you nothing, getting snotty with us gets you nowhere ». Jolie l’hypocrisie.

          • [^] # Re: Drew ? J'ai un peu du mal avec ce type

            Posté par  (site web personnel, Mastodon) . Évalué à 4.

            Surtout que ce n'est pas une dépendance. C'est compilé. Tu installe Pyhton. Si tu veux utiliser la lib en question, tu télécharge le code Python et la partie binaire qui a été écrite en Rust ou C peu importe.

            Pour compilé il faut avoir Rust, mais Rust est disponible sur les distrib et si ce n'est pas le cas, il y a la cross compilation.

            Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

            • [^] # Re: Drew ? J'ai un peu du mal avec ce type

              Posté par  . Évalué à 6.

              Surtout que ce n'est pas une dépendance. C'est compilé.

              C’est pas une dépendance « runtime », c’est une dépendance si tu tiens absolument à compiler le module toi même.

              Mais à moins d’être mainteneur d’une distribution, t’as juste pas besoin de le faire :

              $ rustc
zsh: command not found: rustc
$ python3 -m pip install --user --upgrade cryptography
Requirement already satisfied: cryptography in /usr/lib/python3/dist-packages (3.3.2)
Collecting cryptography
  Downloading cryptography-3.4.7-cp36-abi3-manylinux2014_x86_64.whl (3.2 MB)
     |████████████████████████████████| 3.2 MB 1.4 MB/s
Collecting cffi>=1.12
  Downloading cffi-1.14.5-cp39-cp39-manylinux1_x86_64.whl (406 kB)
     |████████████████████████████████| 406 kB 1.6 MB/s
Collecting pycparser
  Downloading pycparser-2.20-py2.py3-none-any.whl (112 kB)
     |████████████████████████████████| 112 kB 1.4 MB/s
Installing collected packages: pycparser, cffi, cryptography
Successfully installed cffi-1.14.5 cryptography-3.4.7 pycparser-2.20
$ python3
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cryptography
>>>

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 7.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Drew ? J'ai un peu du mal avec ce type

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

            Toi tu présentes bien les choses, posément et sans prendre les gens de haut. C'est ce qui fait défaut au gars (et si ça se trouve il n'a même pas vu le souci de portabilité que tu évoques, mais juste « moi je fais du C et toi tu veux faire du Rust parce-que t'est qu'une sous-m.rd. incapable de la base en C » ou pas loin.)

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

            • [^] # Re: Drew ? J'ai un peu du mal avec ce type

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

              J'ai découvert cette régression l'autre jour, car un développeur m'a appelé à l'aide sur son poste de travail pourquoi je dois installer Rust tout d'un coup? moi je fais du Python.

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

              • [^] # Re: Drew ? J'ai un peu du mal avec ce type

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

                Il t'a pas appelé pour te demander pourquoi il devait installer gcc alors qu'il faisait du python ?

                Si il doit installer rust pour compiler le nouveau module il devait avoir gcc pour compiler l'ancien.

                Matthieu Gautier|irc:starmad

                • [^] # Re: Drew ? J'ai un peu du mal avec ce type

                  Posté par  (site web personnel) . Évalué à 5. Dernière modification le 26 mars 2021 à 21:26.

                  Python a toujours eu besoin du C pour les libs natives, l'acceptabilité est plus forte.

                  Maintenant Python a besoin de Rust.

                  Demain ce sera quoi? Python aura besoin de C, Rust, Golang, Ziglang et le langage de Drew ?

                  Pourquoi pas, mais est-ce une bonne chose de bloater une langage avec d'autres langages ?

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Drew ? J'ai un peu du mal avec ce type

            Posté par  . Évalué à 4.

            Pour le coup, son argumentaire fait sens.

            Et bien qu’il fork la librairie et qu’il se tape la maintenance du code C.

          • [^] # Re: Drew ? J'ai un peu du mal avec ce type

            Posté par  (site web personnel, Mastodon) . Évalué à -1.

            Ton argument de sécurité ne tiens pas. Rust est un langage compilé, il n'y a donc pas besoin que ton OS supporte le langage pour avoir un programme Rust, il faut juste le binaire et éventuellement des dépendances.
            C'est toute la différence avec Python, PHP ou même Java qui ont besoin d'un interpréteur ou d'une VM qui peut avoir lesquels peuvent avoir leur propre failles en plus des failles du programme.

            Après si ton programme n'est pas a jour ou ses dépendances, c'est un problème mais comme n'importe quel autre logiciel.

            La différence fondamental c'est qu'un pirate ne pourra pas envoyer des données qui exploiteront une faille de l'interpréteur. Il faudra qu'il se contente des failles du programme (et pour un programme Rust elles sont mécaniquement réduites).

            Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

            • [^] # Re: Drew ? J'ai un peu du mal avec ce type

              Posté par  (site web personnel) . Évalué à 3. Dernière modification le 26 mars 2021 à 15:39.

              C'est toute la différence avec Python, PHP ou même Java qui ont besoin d'un interpréteur ou d'une VM qui peut avoir lesquels peuvent avoir leur propre failles en plus des failles du programme.

              Ça marche aussi avec le compilateur qui peut introduire ses propres failles en plus des failles du programme :-)

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Drew ? J'ai un peu du mal avec ce type

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

          Le rapprochement entre cette intervention et celle citée dans le commentaire parent est intéressante. Dans un cas il insulte l'utilisateur (qui avait été irréprochable AMHA) en disant que les volontaires développant sway ne sont pas à son service, d'un autre il insulte les volontaires qui développent une lib crypto parce qu'ils ne devraient pas faire ce qui leur plaît mais ce que veulent (certains de) leurs utilisateurs.

  • # Chouette

    Posté par  . Évalué à 10.

    Bientôt un nouveau taptempo !

  • # DaveC

    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 29 mars 2021 à 15:36.

    Si je devais créer un langage il ressemblerait à du C avec de la généricité, des paramètres nommés, le moins de syntaxe spéciale possible et surtout aucune exception/panic/…

    La seule boucle for, car je ne souviens pas la dernière fois que j'ai fait un while ou do while.

    import log;

main := fun(args: array<type: string>, return: void) {
    greetings := array<type: string >(
        "Hello, world!",
        "¡Hola Mundo!",
        "Γειά σου Κόσμε!",
        "Привет мир!",
        "こんにちは世界！",
    )

    for entry := greetings.entries {
        log.println(entry.value)
    }

    log.println(0 / 0, " égale la tête à toto")
}

    Envoyez moi, 42 millions d'euros et je verrais comment le réaliser !

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Suivre le flux des commentaires

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