Re: go 2.0

Et je trouve simplificateur le typique « ignore complètement les 40 dernières années de recherche » dont est souvent victime Go

Non, c'est vrai. On peut faire des types sommes et du filtrage de motif en restant tout à fait dans le "budget complexité" de Go, regarde la façon (pas très compliquée) dont ils sont présentés dans OCaml ou Swift par exemple. Pour l'ajout des génériques, je pense que c'est un peu plus compliqué (avoir des génériques qui se mélangent bien à un style objet/interfaces où le sous-typage est omniprésent n'est pas évident), il faudrait peut-être changer certains choix de conception. Mais le fait de n'avoir pas vraiment essayé montre quand même un choix fort de faire un langage sans vraie capacité d'abstraction.

C'est clair en voyant Go que c'est une version améliorée de C->Alef->Limbo qui ignore complètement ce qui s'est fait en recherche en langages dans les autres équipes que celles des gens qui ont fait Go (le résultat est quelque chose qui est très proche de Algol/Modula).

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

Pour (1), une réponse possible est "parce que le langage a beaucoup d'utilisateurs et que développer des outils peut donc leur rendre service". C'est une réponse raisonnable et je la respecte. Dans la communauté des langages, des compilateurs etc., il y a un peu deux modes de travail, (a) travailler sur les langages existants, même si c'est moche et injustement difficile, pour améliorer la vie des utilisateurs, et (b) concevoir de nouveaux langages meilleurs pour montrer la voie, même si on sait qu'ils seront peu utilisés et que le transfert principal se fera si des langages plus utilisés reprennent certains aspects. Une personne donnée peut travailler sur les deux aspects à la fois selon ses projets, travailler sur Go serait clairement le cas (a), personnellement j'ai plutôt tendance à m'inscrire dans l'approche (b)—j'ai tendance à préfèrer augmenter la quantité de beauté dans le monde qu'atténuer les souffrances des gens qui vivent dans le laid, mais après chacun son goût. Il y a des gens qui travaillent sur des outils pour Go (par exemple des vérifications de cohérence de protocoles concurrents, à base de canaux comme en Go plutôt qu'en acteurs comme Erlang, plus étudiés précédemment).

Par ailleurs, indépendamment de Go, le langage, qui n'a aucun intérêt ou presque, il y a des choses intéressantes dans Go, en particulier l'idée que finalement on peut rendre un langage bof très agréable à utiliser si on met le paquet sur les outils. C'est hors du cadre discuté dans mon journal ci-dessus, et personellement je ne comprends pas encore très bien, scientifiquement, l'articulation entre un langage de programmation et les outils qui l'entourent. Je pense que c'est une questoin intéressant et que c'est en étudiant des cas d'usage, comme Go, qu'on peut commencer à cerner ces questions—ou au moins avoir des idées de bonnes idées à reprendre pour l'outillage de langages qui nous intéressent plus.

(Le travail sur le runtime concurrent de Go est aussi relativement intéressant, je crois, mais ça ce n'est pas mon domaine.)