gasche a écrit 1151 commentaires

La différence, il me semble, c'est qu'ajouter la fonctionnalité "mettre ici l'adresse mail à montrer sur son profil" est assez facile, et demande beaucoup moins d'efforts qu'implémenter les MPs. C'est pour ça que je pense que c'est une bonne priorité. Mais après si toi tu tiens aux MPs et tu n'as absolument pas envie de montrer une adresse email que d'autres personnes risqueraient de connaître déjà, n'hésite pas à ouvrir un ticket de suivi et/ou à envoyer un patch.

Personellement je préfère pouvoir passer par les emails que par des MPs LinuxFR. Les MPs LinuxFR seront forcément moins confortables à l'édition, ne seront pas archivés dans ma boîte mail et donc pas cherchables, vont manquer de 36 fonctionnalités utiles (conversations filées, facilité d'ajouter d'autres personnes (peut-être pas membres de LinuxFR !) dans la conversation, pièces jointes, signatures GPG), avoir une limite de nombre de messages qui va un jour me casser les pieds… la liste est longue et il facile de se convaincre que ce ne sera jamais aussi bien que de laisser les gens utiliser des emails (ou XMPP s'ils préfèrent, etc.). Je ne connais aucun site dont les messages privés sont plus agréables à utiliser que les emails.

(Et on n'a pas besoin de révéler une "adresse personnelle", on donne l'adresse qu'on veut. Je peux me créer une boîte mail 'gasche-linuxfr@…' chez n'importe quel fournisseur email et l'utiliser. Si ça amuse les gens de linuxfr, ils peuvent même monter un serveur mail @linuxfr.org et donner des comptes aux membres qui le demandent.)

Je me rappelle d'un texte d'un codeurs linux qui lisait des papiers de recherche sur un problème précis d'OS qui était majoritairement monocpu, alors que cela n'existe presque plus, et pour des résultats non reproductibles.

Moi je vois aussi que les développeurs du kernel sont très lents à intégrer des idées venant du monde de la recherche, qu'il faut un peu tout leur apporter déjà cuit. Je ne vais pas parler de la recherche en OS que je connais mal, mais sur les tests, il y a eu plein de progrès sur le test aléatoire (concoling testing, etc.), les devs kernels n'ont jamais fait d'effort pour adopter ça dans le noyau (par exemple : en demandant à la Linux Foundation de financer une collaboration avec des universitaires du sujet pour financer une thèse d'application au noyau), et attend que des ingénieurs recodent leurs solutions from scratch (les fuzzers qui commencent timidement à être utilisés dans le noyau). C'est encore pire pour la vérification de programmes / l'analyse statique, où le kernel Linux n'a rien en place, alors que le kernel Windows utilise des annotations riches qui sont vérifiées statiquement depuis des années—pour ce genre de projets il faut que les développeurs soient prêt à spécifier les annotations qui précisent la possession de la mémoire, les informations de taille de pointeurs, etc., on ne peut pas vérifier le code sans en changer une seule ligne.

Je vois la recherche énorme autour du GADT que peu de personnes comprennent.

Bien expliqué et bien implémenté, les GADTs ne sont pas très compliqués, et ils simplifient quand même un certain nombre de choses difficiles à faire sans (Menhir, par exemple, repose sur des GADTs, mais est implémenté avec des Obj.magic en interne car il a été développé avant que ça n'arrive dans le langage; la plupart des bibliothèques avec des types fantômes sont dans cette situation). Il y a des bouts importants de l'écosystème OCaml qui devraient être soit moins sûrs soit moins efficaces sans les GADTs.

Ocaml […] n'a toujours pas de moyen simple d'utiliser du multi-core ou les instructions SIMD.

En même temps (1) il y a peu de moyens "simples" d'utiliser le multi-core et (2) il y a de la recherche là-dessus depuis des années (dont maintenant de la recherche spécifiquement pour OCaml). C'est un peu pareil pour les instructions SIMD, si tu connais une façon simple de les ajouter au langage sans casser les garanties de sûreté du langage, raconte-nous.

Je n'ai pas vu non plus de recherche sur un langage pour la génération de code performant.

Pourtant il y en a plein, c'est peut-être juste que tu n'as pas regardé au bon endroit. LLVM me semble être un exemple, ou alors les travaux sur des DSLs qui se compilent bien vers des GPU par exemple. Si tu veux des références plus précises, peux-tu en dire plus sur ce que tu cherches ? (Quel genre de code ?)

J'ai vu de la recherche sur la compilation du code C (la lib de transformation de boucle utilisé dans gcc), mais pas sur un langage qui permet au compilateur de mieux faire son boulot (unboxing facile, allocation mémoire minime, gestion des instructions assembleurs spécifiques facilités,…).

Il y a pourtant eu pas mal de recherche sur des langages pour la programmation scientifique (X10, Fortress…) dont les aspects que tu mentionnes (à part l'assembleur je pense) étaient des aspects importants.

La recherche semble aussi focaliser sur la recherche du langage ultime. Mais comment fait-on la migration des centaines de millions de lignes de code existantes ? Comment assurer une transition progressive ?

Il y a des deux dans la communauté scientifique, des gens qui étudient la conception de meilleurs langages/outils (à utiliser dès le départ pour de futurs projets), et des gens qui cherchent à faciliter l'usage des langages existants malgré leurs défauts. Tu vas trouver le genre de choses que tu mentionnes chez les gens qui sont partisants de la seconde approche.

Par exemple, Michael Hicks et ses collaborateurs à l'université du Maryland ont travaillé depuis 2001 sur le problème de "Dynamic Software Update" pour le C (et les langages proches de C) et le Java, donc la question de comment migrer d'une version à l'autre d'une application pendant qu'elle tourne (avec des problématiques proches de ta question sur les migrations de schéma de bases de données, qui j'imagine a aussi été très étudiée mais je ne connais pas la recherche en bases de données).

(Maintenant il y aussi de la recherche sur la migration automatique de code en utilisant du machine learning, par exemple la recherche de Tien Nguyen à l'université du Texas.)

J'utilise plein de listes gérées par Sympa, et ça marche très bien, sauf les archives web qui sont presque inutilisables. C'est en particulier un point contentieux pour l'utilisation d'une mailing-list pour la communauté du langage OCaml, avec des membres qui demandent de passer à d'autres solutions (comme un forum web) à cause de la difficulté d'utilisation des archives. Entre autres:

• suivre un thread ne marche pas dès que le thread est coupé sur deux mois, on ne peut pas passer d'un mois à l'autre en suivant le thread; la fonctionnalité est donc la plupart du temps inutilisable

• la recherche est très difficile à utiliser correctement, en particulier elle va chercher seulement dans le dernier mois par défaut (du coup si on arrive sur une archive, on met comme chose à chercher dans la barre de recherche principale exactement le nom d'un topic un peu plus ancien, on va avoir un résultat vide)

Mon usage personnel des archives est de trouver un lien web pérenne pour faire référence à un mail envoyé sur la liste. Ce qui marche bien c'est de faire d'abord la recherche dans ma boîte mail, noter la date précise du mail, et ensuite aller chercher le mois correspondant dans l'archive Sympa — je pense que ce n'est pas optimal.

Juste une question : quand tu parles à quelqu'un, est-ce que tu as la possibilité de revenir sur ce que tu as dit pour le changer ?

Je ne vois pas le rapport. Depuis quand le but des commentaires est d'imiter exactement une conversation humaine ?

Quand je parle à quelqu'un, normalement il n'y a pas des dizaines de personnes qui vont venir derrière ré-écouter ce qu'on a dit, aujourd'hui ou dans 10 ans, et qui bénéficieraient d'une clarification de la conversation.

Si on peut se donner une fonctionnalité qui améliore les discussions par rapport à une conversation physique, pourquoi s'en priver ?

Pour que [l'historique] soit utilisable, il faudrait que lorsque l'on lit la réponse à un commentaire corrigé, on puisse avoi la version d'origine et la version corrigée en simultané.

Quand on voit le message de quelqu'un qui a été édité, on n'a pas en général besoin d'aller consulter l'historique. L'historique n'est là que si on a l'impression que certaines personnes ont répondu à une version précédente du message et qu'on veut être sûr de bien comprendre l'histoire—en particulier il sert de témoin à une utilisation abusive de l'édition. Ce serait un cas ultra-minoritaire, et non pas systématique.

Sur le thème du "ah oui mais utiliser des outils pas adaptés c'est pas bon, on le savait déjà", personellement je trouve qu'il y a quand même une différence de fond entre la généricité, qui me semble être une caractéristique inhérente à la programmation, et le fait de bien couvrir ou pas tel ou tel domaine applicatif par exemple. C'est une chose de dire "t'aurais pu le savoir que faire des logiciels de trading haute-fréquence en PHP c'est une mauvaise idée" : le domaine applicatif vient avec tout un tas de contraintes (volumes de données, temps de latence, etc.) dont on peut raisonnablement dire : "tel langage risque de coincer" ou, dans l'autre sens, "il y a une chance d'avoir ce domaine dans le logiciel que je veux construire et faire évoluer" (on peut se retrouver à avoir besoin de choses qu'on n'avait pas prévu au départ, mais on a quand même une vague idée d'ensemble).

À l'inverse, "avoir besoin d'une structure de donnée générique", c'est un besoin qui me semble pouvoir apparaître dans tous, mais alors vraiment tous les domaines applicatifs. Ce n'est même pas un besoin qui diminue quand on a une application de petite taille (contrairement au "j'ai besoin de refactorer mon code et je ne sais plus si ça marche" qui est critiqué pour certains langages dynamique), puisqu'il peut apparaître quand on choisit d'utiliser une bibliothèque tierce pour construire notre petit programme.

Bien sûr, une des raisons d'être de la recherche en systèmes de typage vient du fait que, quel que soit le système, il y a des formes de généricité plus avancées encore qu'on risque d'empêcher. (Si tu as les génériques, il faut se mettre à réfléchir à la variance et on préfère éviter les wildcards; ou alors au polymorphisme de sorte supérieure, etc.) Donc tous les langages typés sont, dans une certaine mesure, confrontés à ce problème. Mais je pense que "structure de données génériques" est quand même un besoin de généricité qui va apparaître particulièrement tôt et souvent.

L'argument sur le nombre d'occurrences de type-switches n'est pas très convaincant : il suffit que quelques bibliothèques de base l'adoptent en interne, et tout le code qui s'en sert a perdu l'information de typage entre ce qui entre dans ces bibliothèques et ce qui en sort. Ce qui va probablement se passer, à court ou moyen terme, puisque c'est une propriété de la généricité d'être plus utile dans les bibliothèques de base (ou alors on s'en passe et le code devient plus lourd, plus redondant).

Si quelqu'un m'envoie un patch pour pouvoir éditer des contenus avec un historique, je l'intégrerais avec plaisir.

C'est la première fois que je lis ça et c'est nouveau pour moi. On verra quand j'aurai du temps.

Boarf. Je pense que Bruno répondait à l'aspect "sur les autres sites ça ne me pose pas de problème" (je ne fréquente pas Hacker News donc ce n'est pas incompatible). Par ailleurs si tu vas lire la discussion qu'il cite, clairement la personne qui a écrit ce message est hyper-agressive (ce qui s'est passé c'est que le type qui a édité a ajouté "Clarification: …" et pas "Edit: …", ce qui est une erreur de jugement mais pas profondément malhonnête), et que d'autres gens dans la discussion sont trop agressifs aussi. À partir de là, il y aurait pu avoir un problème quoi qu'il arrive, dans un site qui ne permet pas l'édition (l'auteur original aurait posté un second commentaire et le râleur serait venu dire "non mais tu changes d'avis d'une fois sur l'autre c'est super malhonnêtre") ou dans un site avec historique (une personne aurait pu ne pas aller regarder l'historique et lancer une bataille de toute façon).

Encore une fois, sur aucun des autres sites que j'utilise, et qui permettent tous l'édition, cela n'est vu comme un problème. Un soucis de maturité des comportements sur LinuxFR ? De toute façon, garder l'historique des éditions (permettre de consulter les anciennes versions du message) élimine cette inquiétude.

Il suffit de laisser les gens choisir de donner un email à afficher (ou pas, et pas forcément celui utilisé pour communiquer avec LinuxFR-le-site). Si les gens ne veulent pas de spam, ils ne mettent pas d'email, et s'ils veulent un pseudonyme précis ou quoi ils choisissent la bonne adresse email à montrer. C'est expliqué dans l'entrée de suivi.

Je suis d'accord avec toi sur le fait que les emails sont plus pratiques, mais ils sont quasiment inutilisables sur LinuxFR puisque le site ne permet pas aux membres de montrer une adresse email aux autres. J'ai ouvert une entrée de suivi il y a des années à ce sujet, Permettre aux membres de rendre leur adresse mail publique, mais il semblerait que cette fonctionnalité, qui me semble basique, n'est pas assez convaincante ?

Permettre l'édition pendant 5 minutes est mieux que rien, mais ça ne me convient pas. Je repère souvent des modifications à faire après-coup pendant une discussion, quand la limite est passée. C'est évidemment encore plus le cas pour les journaux, où je peux mettre du temps à repérer une faute ou à ce qu'elle me soit signalée.

La solution est alors de permettre de voir les version précédentes (ça se fait sur certains sites), mais c'est du taf à intégrer correctement.

Je serais prêt à aider à implémenter cette fonctionnalité.

Ce qui me manque le plus sur LinuxFR c'est la possibilité d'éditer ses propres contenus. J'essaie autant que possible d'avoir des échanges construits et intéressants, et c'est très frustrant quand on relit une conversation de voir des typos, des petites fautes ou défauts de formulation dans ses propres messages et de ne pas pouvoir les corriger. (C'est évidemment encore pire pour les journaux, mais le problème se pose dans les deux cas.)

Tous les autres sites que je fréquente (à part les mailing-lists) permettent cela, et ça se passe sans problème. LinuxFR est en retard là-dessus et, pour moi, cela nuit beaucoup au confort de participation.

La partie du message qui m'intéressait c'est "sum types are just types". Le traitement proposé des interfaces (comme des existentiels je suppose) est indépendant.

Une interface Go c'est:
- une valeur à un certain type
- un morceau d'information qui permet, quand on pattern-matche dessus, d'apprendre l'identité de (en fait c'est string, ou int, etc.)—il serait naturel de représenter cela comme un cas particulier de type algébrique (extensible) généralisé, GADT, mais on peut aussi définir des règles de typage spécifique comme Go fait pour les "type switches"
- de l'information (la vtable) sur où trouver les méthodes de l'interface, que l'on peut voir comme un produit/record des fonctions de l'interface et dont on peut appeler le type
- le tout empaqueté dans un type existentiel qui rend la valeur de "abstraite":

Il pourrait être intéressant de se demander si ça vaudrait le coup de donner accès à ces composants de façon indépendante :

• Le fait que les existentiels sont forcément de la forme veut dire que tu ne peux pas avoir une interface qui n'est pas attachée à précisément une valeur du type. Généraliser permettrait plus d'expressivité. En Haskell par exemple tu peux définir une classe de type Default a qui est disponible pour les types a qui ont une valeur par défaut, et on veut pouvoir invoquer la méthode default :: a sans avoir de valeur de ce type sous la main. Il y a aussi plein de cas où un existentiel trimballe plusieurs valeurs de type , une liste de valeurs, etc.

• Dans certain cas tu veux que les gens n'aient pas accès au type dynamique de la valeur, pour pouvoir protéger ton abstraction (et donc avoir la garantir que tu peux changer le type concret sans casser le code de l'utilisateur de ta bibliothèque).

Ça semble être utile pour des choses comme un Marshall type-safe automatique d'une structure quelconque ou avec quelques restrictions (donc pas comme celui d'OCaml, qui n'est pas type-safe à la lecture) : je serais intéressé de savoir s'il y a des alternatives sans réflection, à la rigueur à coup de deriving semi-automatisé.

Les classes de type marchent assez bien pour gérer le type Dyntype a, parce que c'est typiquement le genre de valeurs que tu veux passer implicitement, et pour lequel tu n'as pas envie/besoin d'avoir plusieurs implémentations pour un même type. Sinon on peut ajouter cette construction en dur dans le langage, ça a été prototypé pour OCaml (Runtime types in OCaml), mais l'interaction avec les barrières d'abstraction (le système de module) est un problème délicat.

Il y a plusieurs composants dans le projet Why3:
- un langage fonctionnel impur, WhyML, pensé pour écrire des programmes certifiés en grande partie par des prouveurs automatiques
- tout un outillage (interface de programmation et interfaces graphiques) pour envoyer des conditions de preuve exprimées dans un langage intermédiaire (en particulier celles générées par la vérification d'un programme WhyML) vers tout un tas de prouveurs automatiques différents, les faire tourner en parallèle, ramener les résultats à l'utilisateur, etc.

À ma connaissance il n'y a pas de "projet industriel" écrit en WhyML, le langage d'entrée principal de Why3—donc oui les exemples sont ce que les gens qui travaillent dessus vont faire par intérêt ou pour tester les limites de l'outil. Par contre, la deuxième partie a été réutilisée par les gens de SPARK/Ada pour vérifier statiquement une partie des contrats d'un programme Ada (et donc ne pas avoir besoin de retester ces contrats dynamiquement), et il paraît que ça marche plutôt bien.

C'est pour ça que Blackknight t'a parlé de Why3 quand tu parlais de "vérifier des contrats compile-time" : la plateforme Why3 est utilisée par une implémentation SPARK/Ada comme une plateforme de communication/collaboration entre un programme annoté avec des spécifications ou contrats et plein de solveurs automatiques pour les vérifier.

Mais les problèmes que tu pointes là sont du ressort de la conception de la bibliothèque standard (le choix d'avoir mis en avant la plus concrète (et donc plus simple) ou plus abstraite (et donc plus générique)) et des choix de documentation, pas de la définition du langage lui-même (on ne parle pas de changer les mots-clés, le typage, etc.) : on pourrait tout à fait avoir des classes de type correspondant aux interfaces Reader et Writer de la bibliothèque standard Go, et ce serait aussi simple à utiliser.

(Il y a une différence entre les deux usages, qui est qu'en Haskell (ou avec les implicites en Scala) il faut déclarer explicitement "le type truc est une instance de Reader avec telles méthodes", alors qu'en Go c'est automatique à partir du moment où une fonction du nom recherché existe. Je ne pense pas que l'un soit plus simple que l'autre pour un débutant. Par contre ça a un impact important sur la flexibilité du mécanisme, son ergonomie à l'usage et sa modularité—il y a des avantages et des inconvénients à chaque approche. On peut détailler un peu si ça intéresse des gens, mais ça concerne des usages plus avancés qui ne sont pas visibles pour le cas simple "classe standard pour la sérialisation".)

Mouais. Les langages dynamiques les plus intéressants sont ceux qui profitent de l'absence des ceintures-bretelles pour faire des choses vraiment marrantes, tant qu'à faire. Le live development à la CLisp où tu redéfinis tes fonctions une par une dans le terminal en expérimentant, voire à la Smalltalk où tu arrêtes le programme au milieu, c'est assez fun. (Et recharger du code à chaud c'est très utile en Erlang.) Générer des classes/types dynamiquement ou faire du monkey patching (Python, Ruby), moi ça ne m'a jamais séduit mais c'est une audace. Implémenter des constructions de folies qu'on n'a pas su bien typer pendant longtemps (les continuations délimitées, le multistage programming). Utiliser l'introspection pour se brancher directement sur des données et les transformer comme si c'était des types natifs du langage. Tout ça.

Je veux bien dire que le typage dynamique c'est quand le type utilisé ne sert à rien, mais je ne voudrais pas dire que les langages dynamiques se résument à ça.

Disons que si on décide d'utiliser un langage au typage statique, c'est aussi pour bénéficier d'une certaine sûreté apportée par le fait que le typeur vérifie qu'on fait les choses à peu près correctement. C'est un peu dommage de se retrouver complètement abandonné, et de devoir se reposer sur le fait de suivre un pattern sans faute d'inattention (et de payer le coût de la maintenance supplémentaire, par exemple quand on change d'avis sur le type dynamique qu'on veut transporter), dès qu'on veut définir une structure de donnée un peu générique (donc suivre des bons principes de programmation).

Mais je pense que tu sais tout ça et qu'on est d'accord.

(Pour information, moi aussi je trouve que les modules OCaml sont trop compliqués — dans les détails avancés. C'est très, très difficile de faire un bon système de modules, en fait c'est un problème de recherche ouvert.)

Je n'essaie pas de dire que les interfaces devraient être remplacées par les classes de types, ce sont deux fonctionnalités très différentes (même si elles sont utilisées en partie pour répondre au même besoin).

Puisque tu es intéressé par le fait de discuter des interfaces, poussons un peu la discussion. Go utilise les interfaces de plein de façon différentes :

1. pour présenter une interface commune à plein de types différents ayant des opérations en commun, en partant du principe qu'il n'y a qu'une seule interface possible pour chaque type; c'est la façon dont marche la généricité sur Writer/Reader par exemple

2. comme un mécanisme de sealed classes (en Scala) du pauvre où on imite les types sommes en donnant une interface commune à un ensemble de types (un pattern assez proche des "empty bases classes" de C++), et on repose sur le dispatch dynamique sur le sous-type (appelé "type switches" en Go)

3. interface{} comme un type existentiel fourre-tout suivi par des upcasts quand nécessaire; c'est la programmation générique du pauvre, comme avec Object en Java.

À mon avis les interfaces sont une approche raisonnable pour (1), à comparer par exemple aux "traits" de Rust. (Les type-classes sont beaucoup plus expressives (elles n'imposent pas d'être toujours attachées à une valeur), mais demandent de savoir coder un moteur d'inférence de type plus riche). Je pense que (2) serait, dans la plupart des cas, mieux fait avec des vraies sommes, et que (3) est toujours autant une aberration que quand c'était fait en Java avec Object.

Pour préciser peut-être (et dé-dramatiser un peu), je ne crois pas qu'il y ait de problème d'incompréhension du fond sur LinuxFR (la communauté est souvent pointue, sur des sujets différents, mais peut s'intéresser à des choses techniques)—et je ne me sens pas découragé par les commentaires. Ce qui me gêne plutôt c'est l'hostilité qui s'installe très vite dans les échanges. Mais dans la phrase que tu cites je faisais remarquer que la réaction des gens qui sont sur la défensive par rapport à Go dans ce fil, au point de ne pas vouloir reconnaître des choses qui sont assez évidentes il me semble, est assez caractéristique et que, évidemment, dans la communauté Go c'est pareil. (Évidemment pour vendre une collaboration à la communauté Go il est prudent de ne pas commencer à leur dire qu'ils ne font pas le job, même quand ce n'est pas faux.)

La question de fond est nuancée est c'est la façon qu'on a de discuter ici (sur LinuxFR) qui lui enlève toute sa nuance. Peut-être que la meilleure façon de communiquer sur ce site c'est de poster un journal, de s'interdire de répondre aux commentaires, et de laisser les gens se débrouiller. Sur le coup c'est difficile de se retenir de commenter.

Tu as pourtant reproché des choses à Go qui demanderaient de changer l'architecture de Go. et qui est difficile à faire aujourd'hui car ce n'est pas cohérent avec l'architecture choisie. Que c'est trop tard.

Tu mélanges ce que j'ai dit sur les types sommes et les génériques, qui sont deux fonctionnalités très différentes.

(J'aime pas trop me mettre à discuter de "ah mais tu as dit", "ah mais non j'avais pas dit…"; je clarifie ici mais je ne répondrai plus sur ce terrain là.)

À chaque version du langage les implémenteurs de Go ré-écrivent leur GC pour être moins naïf qu'avant. Ils auraient les sous de payer quelqu'un pour implémenter les types sommes (et les documenter, et adapter les outils, tout ça) s'ils en avaient envie. Le problème c'est le manque de connaissance et d'envie.

Franchement écrit une proposition propre sur les type sum et poste un lien sur le blog de go 2.0

On en revient aux soucis que j'avais signalés ici:

Alors certes il ne serait pas trop difficile de faire une sémantique formelle pour Go, mais

1. Pourquoi je me casserais les pieds à travailler pour des gens qui trouvent que le travail de ma communauté est inutile ?
2. Pour qu'un langage profite d'un effort de formalisation, il faut que les concepteurs soient prêts à y participer, à éventuellement s'en inspirer pour changer des choses, et à rester en contact avec les gens qui font le modèle formel pour le faire évoluer en tandem avec le langage. Pour Go on n'a aucune assurance que ses auteurs seraient motivés pour jouer le jeu, et on a plutôt les signes qu'ils ne le seraient pas. (Au contraire des gens de Rust, qui ne se sont pas bougés le petit doigt pour une formalisation du langage pendant des années, mais qui ont au moins toujours été accueillants et positifs quand des académiques les contacts pour cela.)

J'ai beaucoup de projets sur lesquels bosser qui m'intéressent, c'est moins motivant de travailler sur les types sommes en Go quand on ne sait pas si les concepteurs/implémenteurs du langage vont y consacrer un quelconque intérêt—il n'y a qu'à voir les réactions de la communauté LinuxFR ici pour voir que ce n'est pas gagné.

Après peut-être que sur le long terme ça serait bénéfique en terme de d'impact sur l'imaginaire collectif des programmeurs, faire le travail de popularisation et de rendre l'idée "mainstream". Peut-être que Swift et Rust suffiront, et qu'on peut laisser Go rester un langage peu intéressant dans son coin ?