OpenD, un fork du langage D qui accueille vos contributions

• Face à l’accumulation des frustrations liées au blocage durable des contributions par la direction actuelle de D, certains contributeurs sont passés à OpenD, un fork du langage D
• Le problème n’est pas tant de savoir si D est closed source, mais plutôt que, même après la publication sous GPL et la sortie de gdc, le mode de développement et la prise de décision ne se sont pas suffisamment ouverts à la communauté
• Les précédents d’Ares/Tango, qui ont ensuite mené à druntime, la baisse d’activité de Phobos, les PR laissées sans suite et le manque d’exécution après « D gripes and wishes » sont avancés comme justifications du fork
• Après le passage à OpenD, les PR, rapports de bugs, support utilisateurs, réunions de la DLF et participations à DConf Online concernant D upstream cessent ; dpldocs.info est maintenu tant que ses coûts sont couverts
• Les bibliothèques et applications D existantes sans contrat de support payant ne bénéficient plus d’une garantie de compatibilité avec D upstream ; la voie de support à long terme se déplace vers la participation à OpenD

---

Pourquoi passer à OpenD

• OpenD est un fork du langage D, né du constat que contribuer à l’upstream via la direction actuelle de D était depuis longtemps extrêmement frustrant
• L’affirmation répétée selon laquelle D serait un langage closed source n’est pas exacte
  • La partie du compilateur spécifique à D a été publiée sous GPL en 2002
  • gdc, le compilateur complet sous GPL, a été publié en 2004
• En revanche, la méthode de développement de D n’était pas suffisamment ouverte, et les critiques persistent sur la très faible prise en compte d’apports significatifs de la communauté dans la prise de décision
• Les fonctions et concepts clés de D, ainsi qu’une grande partie du code D existant, viennent des contributions et du travail de la communauté, mais ne regarder que les cas acceptés peut conduire à un biais du survivant

Un ancien goulot d’étranglement des contributions et le cas Ares/Tango

• L’histoire de D compte de nombreux patchs acceptés, mais aussi beaucoup de patchs restés longtemps sans suite
• Le code aujourd’hui connu sous le nom de druntime provient d’un fork né du refus de Walter d’accepter des contributions de la communauté
  • En 2004, des développeurs qui voulaient coopérer avec l’upstream ont forké D pour ne pas perdre leurs contributions
  • Ce fork s’est d’abord appelé Ares, puis a fusionné avec d’autres efforts communautaires pour devenir Tango
• Tango se présentait comme « The Developer's Library for D » et a fonctionné comme un espace où les développeurs étaient réellement bienvenus pour contribuer
  • L’écosystème Tango contenait de nombreux éléments absents de l’écosystème Phobos
• Après quatre ans de maintien et de popularité du fork, l’upstream a engagé une réconciliation, un mouvement qui a mené au druntime actuel
• L’idée sous-jacente est que, sans le fork Ares/Tango, D n’aurait pas obtenu de position significative sur le marché, et que ce fork a sauvé D d’une situation critique

Une participation en baisse après l’âge d’or

• La période où les développeurs clés de Tango sont revenus et où Andrei Alexandrescu, entre autres, a rejoint le projet est décrite comme un âge d’or du développement de D, relativement ouvert, avec une activité en hausse autour de 2013
• Il est aussi souligné que presque tous les utilisateurs commerciaux de D dépendaient directement de code issu du fork Ares
• Mais les anciennes habitudes n’ont pas disparu, et beaucoup de contributeurs de l’âge d’or ne sont pas restés dans la communauté
  • Certains sont partis explicitement en raison d’un processus défaillant où leur travail n’était pas reconnu
  • D’autres ont réduit leur activité pour des raisons personnelles, et les nouveaux contributeurs ne sont pas restés en nombre suffisant
• L’activité de développement de Phobos a fortement chuté mi-2018, puis a connu deux petites reprises
  • L’ajout par berni44 du formatage de nombres à virgule flottante compatible CTFE
  • L’acceptation du module sumtype de Paul Backus en tant que std.sumtype
• En 2020, après avoir attendu près de trois mois la revue d’une PR, berni44 a annoncé son départ de la communauté ; il est revenu un an plus tard, ce qui a entraîné une récente hausse d’activité de développement de Phobos, avant de repartir quelques mois après
• Dans dmd lui-même, le volume de contributions personnelles de Walter est resté globalement stable, mais la baisse des contributions des autres a fait passer sa part d’environ 1/6 pendant l’âge d’or à environ 1/3 aujourd’hui

Des recueils de critiques répétés, mais peu d’exécution

• Vers Noël 2022, Mike Parker a demandé aux gens d’envoyer une liste de leurs « D gripes and wishes »
• Beaucoup pensaient qu’il n’en sortirait rien, mais les réponses ont été nombreuses
• Environ six mois plus tard, le 18 mai 2023, un document public rassemblant les réponses a été publié
• Les seuls résultats confirmés publiquement depuis se limitent aux objectifs suivants
  • Stabiliser le langage, le compilateur et la bibliothèque standard
  • Améliorer l’écosystème, notamment les outils et le support des bibliothèques tierces
  • Renforcer la communauté, notamment en réorganisant le site web, en mettant à jour les anciens documents et tutoriels, et en refondant le site
• La demande était de « ne pas rester général, mais d’être précis », pourtant la réponse à de nombreuses critiques précises est restée limitée à des bullets d’objectifs très larges
• Le Vision Document 2016H1 contenait déjà des objectifs similaires, comme l’élargissement de la participation, les outils, la stabilité du langage, l’amélioration de la spécification et l’ajout de bibliothèques ; la position est donc qu’il faut de l’exécution, plus que la définition d’objectifs

Ce que change le passage à OpenD

• Les tentatives de contribution à D upstream cessent, au profit d’OpenD, un fork portant sur l’ensemble du compilateur
• L’hébergement de la documentation sur dpldocs.info est tout juste couvert par Patreon et continuera, y compris le support des paquets dub, tant que les coûts seront couverts
  • Il ne recevra pas les mises à jour de D upstream
  • Les fonctionnalités existantes devraient probablement continuer à bien fonctionner
• La partie du blog dédiée au support exclusif de D upstream s’arrête
  • Les statistiques ne seront plus incluses
  • Le nom devient « This Week in ARSD » et pourra plus tard devenir « This Week in OpenD »
• Les PR et rapports de bugs vers D upstream s’arrêtent immédiatement
  • Les éléments qui lui sont utiles ne seront pas envoyés upstream, mais fusionnés dans OpenD
• Le support aux utilisateurs de D s’arrête aussi
  • Par le passé, il consacrait plusieurs heures chaque semaine à aider des utilisateurs de D de différents niveaux, mais il ne garantit désormais plus de répondre aux questions sur D upstream
  • S’il répond, il dira probablement d’essayer OpenD
• Il ne participera plus aux réunions de la DLF, sauf si un changement de gouvernance est accepté comme prérequis
• Il refusera toute invitation à un livestream DConf Online
• Pour les bibliothèques D, les engagements de compatibilité entre les versions internes et les mises à jour des compilateurs externes ne seront maintenus que pour les cibles couvertes par un contrat de support payant
  • Pour les autres utilisateurs, la compatibilité avec D upstream est annulée immédiatement
  • Le code est fourni tel quel, sans aucune garantie explicite ou implicite
  • En rejoignant le fork OpenD, le support de ces bibliothèques se poursuit
• Les applications D, comme les bibliothèques, ne bénéficient plus d’engagement de compatibilité avec D upstream ; conçues à l’origine pour son propre usage, elles ont des garanties de compatibilité encore plus souples

Position restante

• Il indique avoir consacré beaucoup de temps à D au cours des 16 dernières années, et que la majeure partie de sa carrière de programmeur doit beaucoup à D et, avant lui, à Digital Mars C++
• Walter Bright et ses collègues ont eu un grand impact sur sa vie, et Walter est décrit comme un excellent contributeur aux projets de langages de programmation
• Malgré cela, il quitte désormais le D de Walter Bright pour suivre une voie distincte avec OpenD
• Pour qu’OpenD réussisse, il reste beaucoup à faire et le risque d’échec est très élevé, mais il estime que la responsabilité de cet échec ne repose désormais que sur eux, du côté d’OpenD

[GN⁺]

Avis sur Hacker News

• Au moins Walter, et probablement d’autres membres de la direction de D, sont actifs ici, donc il y a de fortes chances qu’ils voient ces commentaires.
  J’aimerais qu’on garde à l’esprit qu’eux aussi sont humains, qu’ils tiennent vraiment à D et que, d’après mon expérience, ce sont fondamentalement des gens corrects qui essaient de faire de leur mieux.

  • Plus de 20 ans ont passé et, dans les faits, presque rien n’a changé.
    Je ne vois pas pourquoi ce serait différent maintenant, et ça ressemble à une répétition de Tango, deuxième partie.
    La seule différence, c’est que le bateau est parti depuis longtemps.
  • C’est vrai, et je suis d’accord pour dire que tout le monde est humain, mais Walter n’est pas le seul ici à tenir à D.
    Si le projet peut mieux fonctionner sous une autre direction, cette possibilité doit être examinée.
    Personnellement, j’aimerais vraiment voir D renaître ; c’est encore aujourd’hui mon langage préféré.
    Il ne s’agit pas d’attaquer Walter ou qui que ce soit d’autre, mais simplement de gens qui essaient de sauver quelque chose qu’ils aiment.

• C’est regrettable, mais quelque chose comme ça devait finir par arriver. On a trop souvent parlé d’un fork de D pendant des années.
  Quand le livre d’Andrei Alexandrescu est sorti en 2010, presque tout ce qui était bien dans D est arrivé dans C#, Java et C++.
  Les implémentations ne sont peut-être pas aussi propres que dans D, mais si l’on peut les utiliser sous une forme ou une autre avec de meilleurs outils et un meilleur écosystème de bibliothèques, la différence ne compte plus tant que ça.
  Trop de temps a été perdu à courir après des fonctionnalités miracles censées attirer les gens, sans même réussir à les stabiliser.
  Andrei semble aujourd’hui plus occupé par C++ et CUDA que par D.
  La renaissance des langages de programmation compilés en natif au cours de la dernière décennie a encore durci la concurrence.
  C’est d’autant plus dommage que la communauté elle-même compte beaucoup de gens formidables avec qui il est agréable d’échanger.

  • Si cela permet au langage de renaître et d’éviter que tout le travail accompli jusqu’ici disparaisse, je considère plutôt que c’est une bonne chose.
    J’utilise Python tous les jours, et beaucoup de choses de D me manquent.
    Sans même parler des performances.

• En regardant D de l’extérieur, j’ai vu quelque chose de similaire.
  Quand Rust était nouveau, le concept de durée de vie (lifetime) a été proposé à la communauté D, mais Walter l’a jugé inutile.
  Quelques années plus tard, Walter est arrivé avec sa propre proposition de durées de vie, suffisamment différente de celle de Rust, et donc moins éprouvée que la proposition précédente de la communauté.
  J’ai maintenant perdu tout intérêt pour D, donc je ne sais pas à quel point la nouvelle fonctionnalité de durées de vie a mûri, mais je serais surpris qu’elle soit aussi utile que celle de Rust.

  • Je ne connais pas très bien les approches des durées de vie dans Rust ou D, mais après une recherche rapide sur le forum, il semble que l’ajout de durées de vie à la Rust dans D aurait nécessité de modifier fortement la conception du langage.
    Toute fonctionnalité implique des compromis : interactions avec d’autres fonctionnalités du langage, charge cognitive, ralentissement de la compilation, complexité de conception de la bibliothèque standard, ruptures de rétrocompatibilité, etc.
    Je ne pense pas qu’il soit raisonnable d’attendre une refonte majeure juste pour prendre en charge une fonctionnalité qu’on aime dans un autre langage.
  • En somme, on peut maintenant avoir un projet qui intègre l’avis de quelqu’un d’autre que Walter.

• Mon groupe de recherche a quitté D pour Rust il y a quelques années à cause du manque de réactivité et de la mauvaise direction prise par le développement du langage.
  J’espère qu’Adam et les autres réussiront avec OpenD, mais j’aimerais qu’ils profitent de l’occasion pour choisir un nom plus distinctif et mémorable.

• Un nouveau modèle de gouvernance ne commence pas par l’annonce d’une liste de nouvelles fonctionnalités, ni par la décision d’en retirer certaines, mais par une discussion sur la gouvernance avec un quorum de parties prenantes intéressées.
  Ce n’est pas un changement de modèle, seulement un changement de régime.
  Il peut y avoir des griefs légitimes, et la manière dont D dépend de Walter comme gardien peut paraître trop stricte à certains.
  Mais la façon dont ce fork a démarré n’est pas un bon signal à long terme.
  Pour réussir, le fork devra obtenir un large soutien et, au final, attirer une part proche de la majorité de la communauté D, pas seulement quelques contributeurs prolifiques.
  Sinon, le fork échouera lui aussi, et l’intérêt pour le projet original sera encore davantage fragmenté, au point de faire disparaître les chances de survie restantes.
  Il faut aussi la capacité et la volonté de le maintenir pendant des décennies.

• Il semble qu’une mise à jour ait été publiée : https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.h... et qu’elle ait suscité un certain intérêt.
  Personnellement, j’aurais trouvé plus amusant de l’appeler Died.
  Cela permettrait une belle formule comme « It never Died », montrerait aussi qu’il s’agit d’un fork, et laisserait de la marge pour orienter le langage dans une nouvelle direction si nécessaire plus tard.
  OpenD donne une impression de compatibilité totale.
  Bien sûr, je n’ai aucun intérêt direct dans cette affaire, et je leur souhaite de réussir.

• Il y a un gros fil sur ce sujet sur le forum D : https://forum.dlang.org/thread/[e-mail]...

  • Le gros fil indiqué ici vient des personnes qui portent le fork — pour l’instant, deux personnes l’ont lancé — et il contient aussi pas mal de réponses détaillées du côté de D qui manquent dans l’article ci-dessus.
    Le billet original porte surtout sur des plaintes liées à des conflits entre personnes, tandis que ce lien contient davantage de discussions techniques.
    À le lire, les personnes qui forkent semblent en réalité vouloir un autre langage, et être prêtes pour cela à accepter plusieurs changements cassant la compatibilité.

• Personnellement, je suis perplexe quant au créneau que viserait D s’il se concentrait pleinement sur le garbage collector
  Il n’a jamais vraiment eu de créneau clairement défini auparavant. En gros, c’était « un C++ 10 % meilleur », et c’était difficile à vendre faute de fonctionnalité killer qui le différencie nettement
  La plupart des gens resteront probablement sur C++ à cause du support existant, des bases de code et de l’écosystème industriel, ou utiliseront Rust pour de nouveaux projets, ou Zig s’ils veulent de la simplicité
  Surtout depuis C++20, on peut dire qu’il existe déjà un « C++ 10 % meilleur »
  Je ne sais pas non plus si se concentrer sur le garbage collector aiderait vraiment beaucoup
  Dans ce cas, il se retrouverait en concurrence avec C# et Java, deux langages qui ont été conçus dès le départ comme des successeurs de C++ avec garbage collection, sûrs et concis, et je vois mal comment il pourrait rivaliser avec eux aujourd’hui
  C# en particulier dispose de fonctionnalités bas niveau et unsafe assez solides, comme les pointeurs bruts, le contrôle des types référence/valeur et de l’agencement mémoire, en plus d’un système de types et d’une réflexion corrects pour un vieux langage orienté objet en priorité, tout en continuant à intégrer des fonctionnalités issues de la famille ML
  Honnêtement, la vision de D m’a toujours semblé confuse
  J’ai lu la documentation de certaines fonctionnalités du langage, comme BetterC, le mode safe et les durées de vie, mais elle était difficile à lire syntaxiquement, avec beaucoup de détails sans être globalement bien expliquée
  Je n’ai pas vraiment ressenti de vision de conception cohérente ni d’objectif clair pour le langage
  L’auteur mentionne bien ce problème, mais leur propre vision ne me paraît pas particulièrement plus claire
  C’est bien d’avoir quelques objectifs techniques concrets à moyen terme, mais on ne voit pas clairement à quoi ils servent
  Je suis programmeur Rust, donc le choix pour mes nouveaux projets personnels est évident, mais si je devais choisir autre chose, j’utiliserais plutôt OCaml, C++, voire C#

  • Pendant longtemps, D a été présenté comme un meilleur C++, et c’était une erreur pour deux raisons
    Premièrement, D est un substitut à C++, mais ce n’est pas C++, et beaucoup de développeurs C++ ont été frustrés par ces différences
    Deuxièmement, D peut faire bien plus que servir de substitut à C++
    Il peut être utilisé pour du scripting, comme langage de programmation généraliste, et surtout pour l’interopérabilité avec C grâce à ImportC et BetterC
    L’un des objectifs du fork est de ne plus s’excuser au sujet du garbage collector
    La bibliothèque standard contient toujours du comptage de références, des pointeurs uniques, etc.
    Si quelqu’un voulait contribuer des fonctions qui évitent le garbage collector, je pense qu’elles seraient acceptées
    Mais dans ce fork, il est probable qu’on verra moins Adam faire des efforts excessifs pour éviter le garbage collector lorsqu’il ajoute de nouvelles fonctions à la bibliothèque standard
    Il estime que la peur du garbage collector est exagérée

• Ces dix dernières années, il y a eu beaucoup à apprendre autour de la gouvernance des langages de programmation
  Quand on observe les langages émergents et en évolution, eux aussi ont connu de grands conflits ou de grosses erreurs liés à la gouvernance
  Je pense désormais que, lorsqu’on évalue un langage de programmation, la gouvernance est un point essentiel à examiner
  Il faut regarder comment ils décrivent leur mode de fonctionnement, comment ils fonctionnent réellement, quels résultats ils ont obtenus jusqu’ici, et à quoi on peut s’attendre pour la suite

  • Je suis d’accord pour dire que c’est un sujet important, mais je ne pense pas qu’il existe de réponse satisfaisante
    L’évolution d’un langage de programmation relève presque de la gestion de la complexité, tout en devant équilibrer les besoins de plusieurs parties prenantes
    Presque tous les conflits de gouvernance naissent lorsqu’un groupe de parties prenantes conteste des exigences essentielles pour un autre groupe, et il n’est pas toujours possible de satisfaire les deux camps
    Le async de Rust est un exemple connu, qui illustre une conception fonctionnelle mais globalement insatisfaisante
    Go est une rare exception : l’équipe principale n’avait pas de raison de respecter toutes les parties prenantes, et disposait des ressources et de la volonté suffisantes pour agir ainsi, mais cela n’a pas empêché certains conflits
  • La situation ne s’est pas améliorée
    Le modèle de rédaction des standards des années 1960 à 1980 était bien meilleur, et limitait aussi les batailles politiques à une courte période

• Je ne vois pas bien quels seraient les aspects négatifs à avoir plusieurs implémentations de compilateur
  Personnellement, je pense que c’est l’une des principales raisons pour lesquelles C s’est autant diffusé
  Les compilateurs peuvent explorer chacun des directions différentes, et les extensions du langage dont la valeur est démontrée finissent par être adoptées par d’autres implémentations, et parfois même par entrer dans le standard sans être trop dénaturées par le processus de consensus en comité

  • Je suis un peu confus, je croyais qu’il y en avait déjà environ trois
    Je pensais qu’il y en avait au moins deux, entre gcc et l’implémentation côté dlang