OpenD, un fork del lenguaje D que da la bienvenida a tus contribuciones

• Ante la acumulación de quejas por contribuciones bloqueadas durante mucho tiempo bajo el liderazgo existente de D, algunos colaboradores se están moviendo a OpenD, un fork del lenguaje D
• El punto central no es si D es de código cerrado, sino que incluso tras la publicación bajo GPL y el lanzamiento de gdc, la forma de desarrollo y la toma de decisiones no han estado lo suficientemente abiertas a la comunidad
• Se presenta como fundamento del fork el caso de Ares/Tango, que más tarde llevó a druntime, la disminución de actividad en Phobos, los PR desatendidos y la falta de ejecución tras “D gripes and wishes”
• Tras el cambio a OpenD, se suspenden los PR, reportes de errores, soporte a usuarios, participación en reuniones de la DLF y en DConf Online para el upstream de D; dpldocs.info seguirá en funcionamiento mientras se cubran los costos
• Las bibliotecas y aplicaciones existentes de D sin contrato de soporte de pago ya no tendrán garantía de compatibilidad con el upstream de D, y la ruta de soporte a largo plazo pasa a la participación en OpenD

---

Por qué se pasaron a OpenD

• OpenD es un fork del lenguaje D, surgido de la percepción de que el proceso para contribuir al upstream a través del liderazgo existente de D llevaba mucho tiempo siendo muy frustrante
• Repetir que D es un lenguaje de código cerrado no es exacto
  • La parte específica de D del compilador se publicó bajo GPL en 2002
  • gdc, el compilador completo bajo GPL, se publicó en 2004
• Aun así, se critica que la metodología de desarrollo de D no ha sido lo suficientemente abierta y que la comunidad ha tenido muy poca participación significativa en la toma de decisiones
• Aunque muchas funciones y conceptos clave de D, así como una parte considerable del código D existente, surgieron del trabajo y las aportaciones de la comunidad, observar solo los casos aceptados puede llevar a un sesgo de supervivencia

Viejo cuello de botella para contribuir y el caso Ares/Tango

• En la historia de D ha habido muchos parches aceptados, pero también muchos que quedaron abandonados por largos periodos
• El código hoy conocido como druntime se originó en un fork creado porque Walter no aceptaba contribuciones de la comunidad
  • En 2004, desarrolladores que intentaban colaborar con el upstream hicieron un fork de D para no perder sus contribuciones
  • Ese fork al principio se llamó Ares y luego, al unirse con otros esfuerzos comunitarios, se convirtió en Tango
• Tango se presentaba como “The Developer's Library for D” y funcionó como un espacio donde las contribuciones de los desarrolladores realmente eran bienvenidas
  • El ecosistema de Tango tenía muchos elementos que no existían en el ecosistema de Phobos
• Después de que el fork se mantuviera y ganara popularidad durante cuatro años, el upstream buscó reconciliarse, y de ese proceso surgió lo que hoy es druntime
• La idea de fondo es que, sin el fork Ares/Tango, D no habría logrado una posición relevante en el mercado, y que ese fork salvó a D en un momento crítico

Menor participación tras la época dorada

• El periodo en que regresaron desarrolladores clave de Tango y se unieron personas como Andrei Alexandrescu se describe como una etapa relativamente abierta del desarrollo de D y una época dorada con mayor actividad alrededor de 2013
• También se enfatiza que casi todos los usuarios comerciales de D dependían directamente de código surgido del fork Ares
• Sin embargo, los viejos hábitos no desaparecieron, y muchos de los colaboradores de esa época dorada ya no permanecen en la comunidad
  • Algunos se fueron explícitamente señalando un proceso roto en el que su trabajo no era valorado
  • Otros redujeron su actividad por motivos personales, y no se mantuvo una cantidad suficiente de nuevos colaboradores
• La actividad de desarrollo de Phobos cayó fuertemente a mediados de 2018, y después solo hubo dos pequeños repuntes
  • La incorporación por parte de berni44 de formato de punto flotante apto para CTFE
  • El caso del módulo sumtype de Paul Backus, adoptado como std.sumtype
• berni44 dijo en 2020 que dejaría la comunidad tras esperar casi 3 meses por la revisión de un PR; regresó un año después y provocó un aumento reciente en la actividad de desarrollo de Phobos, pero volvió a irse unos meses más tarde
• En el propio dmd, las contribuciones personales de Walter se han mantenido más o menos constantes, pero al disminuir las de otras personas, su proporción pasó de cerca de 1/6 en la época dorada a alrededor de 1/3 en la actualidad

Recolección repetida de quejas y poca ejecución

• Cerca de Navidad de 2022, Mike Parker pidió a la gente que enviara una lista de “D gripes and wishes”
• Muchas personas pensaban que no habría resultados, pero hubo muchas respuestas
• Aproximadamente 6 meses después, el 18 de mayo de 2023, se publicó un documento público que reunía las respuestas
• Desde entonces, el único resultado confirmado públicamente fue el establecimiento de los siguientes objetivos
  • Estabilizar el lenguaje, el compilador y la biblioteca estándar
  • Mejorar el ecosistema, incluyendo herramientas y soporte para bibliotecas de terceros
  • Fortalecer la comunidad, incluyendo ordenar el sitio web, actualizar documentación y tutoriales antiguos, y rediseñar el sitio
• Aunque se pidió “no escriban en términos generales, sean específicos”, muchas respuestas a quejas concretas se quedaron en bullets de objetivos amplios
• Como el Vision Document 2016H1 ya tenía objetivos similares sobre ampliar la participación, herramientas, estabilidad del lenguaje y mejoras a la especificación, además de nuevas bibliotecas, la postura aquí es que hace falta ejecución más que fijación de objetivos

Qué cambia con el paso a OpenD

• Se detienen los intentos de contribuir al upstream de D y se trasladan a OpenD, un fork del compilador completo
• El alojamiento de documentación en dpldocs.info está apenas cubierto por Patreon, y seguirá operando, incluido el soporte para paquetes de dub, mientras los costos se mantengan cubiertos
  • No recibirá actualizaciones del upstream de D
  • Es probable que las funciones existentes sigan funcionando bien
• En el blog se descontinúa la parte de soporte dedicada exclusivamente al upstream de D
  • Las estadísticas ya no se incluirán
  • El nombre cambia a “This Week in ARSD” y quizá más adelante a “This Week in OpenD”
• Los PR y reportes de errores para el upstream de D se suspenden de inmediato
  • Lo que sea útil para uno mismo no se enviará al upstream, sino que se integrará en OpenD
• También se suspende el soporte a usuarios de D
  • Antes se dedicaban varias horas cada semana a ayudar a usuarios de D con distintos niveles de experiencia, pero ahora no se garantiza respuesta a preguntas sobre el upstream de D
  • Si se responde, es probable que se les diga que prueben OpenD
• No se asistirá a las reuniones de la DLF salvo que se acepte como condición previa un cambio de gobernanza
• También se rechazará cualquier invitación a livestreams de DConf Online
• Las bibliotecas de D mantendrán una promesa de compatibilidad entre versiones internas y actualizaciones de compiladores externos solo para quienes tengan contrato de soporte de pago
  • Para los demás usuarios, la compatibilidad con el upstream de D queda cancelada de inmediato
  • El código se proporciona tal cual, sin garantía expresa ni implícita de ningún tipo
  • Si se unen al fork OpenD, el soporte de esas bibliotecas continuará
• Las aplicaciones de D, igual que las bibliotecas, tampoco ofrecen promesa de compatibilidad con el upstream de D, y como originalmente fueron diseñadas para uso propio, esa garantía de compatibilidad es todavía más laxa

Postura final

• Se afirma haber dedicado mucho tiempo a D durante los últimos 16 años y que la mayor parte de la carrera en programación se debe a D y antes de eso a Digital Mars C++
• Se reconoce que Walter Bright y sus colegas han tenido un gran impacto en su vida, y que Walter es un excelente contribuyente a los proyectos de lenguajes de programación
• Aun así, ahora deja atrás el D de Walter Bright y toma un camino separado llamado OpenD
• Para que OpenD tenga éxito hay mucho trabajo por hacer y la probabilidad de fracaso es muy alta, pero ahora se considera que la responsabilidad de ese posible fracaso recae únicamente en ellos del lado de OpenD

[GN⁺]

Opiniones de Hacker News

• Al menos Walter, y probablemente otros miembros del liderazgo de D, también participan por aquí, así que es muy probable que vean estos comentarios.
  Ojalá recordemos que ellos también son personas, que realmente aprecian D y que, según mi experiencia, son gente básicamente buena que intenta hacer lo mejor posible.

  • Han pasado más de 20 años y casi nada cambió de verdad.
    No sé por qué ahora sería distinto, y se siente como una repetición de Tango parte 2.
    La diferencia es que ahora el barco ya zarpó hace mucho tiempo.
  • Es cierto, y estoy de acuerdo en que todos son personas, pero Walter no es el único aquí que aprecia D.
    Si el proyecto puede ir mejor con otro liderazgo, esa posibilidad debería evaluarse.
    Personalmente, de verdad quiero que D reviva; sigue siendo mi lenguaje favorito.
    No se trata de atacar a Walter ni a nadie más, sino de personas que intentan salvar algo que les gusta.

• Es una lástima, pero esto al final era inevitable. Durante años se habló demasiado de un fork de D.
  Cuando salió el libro de Andrei Alexandrescu en 2010, casi todo lo bueno que tenía D terminó entrando en C#, Java y C++.
  Puede que sus implementaciones no sean tan limpias como en D, pero si puedes usar algo parecido dentro de un ecosistema con mejores herramientas y bibliotecas, esa diferencia no importa tanto.
  Se perdió demasiado tiempo persiguiendo funcionalidades doradas que atrajeran gente, y ni siquiera lograron estabilizarlas.
  Andrei también parece estar más ocupado últimamente con C++ y CUDA que con D.
  A eso se sumó el renacimiento de los lenguajes de programación que compilan a nativo durante la última década, lo que hizo la competencia aún más dura.
  Por eso da todavía más pena: en la comunidad hay mucha gente excelente con la que es agradable conversar.

  • Si gracias a eso el lenguaje revive y no se pierde todo el trabajo hecho hasta ahora, más bien me parece una buena noticia.
    Uso Python todos los días y hay muchas cosas de D que extraño.
    Ni hablar del rendimiento.

• Mientras miraba D desde afuera, vi algo parecido.
  Cuando Rust era nuevo, se propuso en la comunidad de D el concepto de lifetimes (tiempos de vida), pero Walter lo consideró innecesario.
  Unos años después, Walter presentó su propia propuesta de lifetimes, lo bastante distinta de la de Rust, y por eso estaba menos validada que la propuesta anterior de la comunidad.
  Ahora ya perdí el interés en D, así que no sé qué tan madura está la nueva funcionalidad de lifetimes, pero me sorprendería que fuera tan útil como la de Rust.

  • No estoy muy familiarizado con el enfoque de lifetimes de Rust o D, pero buscando rápidamente en los foros parece que meter lifetimes al estilo Rust en D habría requerido cambiar bastante el diseño del lenguaje.
    Cualquier funcionalidad implica compromisos: interacción con otras funcionalidades del lenguaje, carga cognitiva, menor velocidad de compilación, complejidad en el diseño de la biblioteca estándar, ruptura de compatibilidad hacia atrás, etc.
    No me parece razonable esperar una gran reestructuración solo para soportar una funcionalidad que a uno le gusta de otro lenguaje.
  • Ahora, en vez de tener la opinión de Walter, podrán tener un proyecto con la opinión de otra persona.

• Mi grupo de investigación dejó D hace unos años y se pasó a Rust por la falta de respuesta y por una mala dirección en el desarrollo del lenguaje.
  Espero que Adam y los demás tengan éxito con OpenD, pero ojalá aprovechen esta oportunidad para elegir un nombre más distintivo y memorable.

• Un nuevo modelo de gobernanza no empieza declarando una lista de nuevas funcionalidades ni decidiendo quitar algunas, sino reuniendo un quórum de partes interesadas para discutir la gobernanza.
  Eso no es un cambio de modelo, sino un cambio de régimen.
  Puede haber quejas legítimas, y la forma en que D depende de Walter como guardián puede resultarle demasiado estricta a algunas personas.
  Pero la forma en que empezó este fork no es una buena señal a largo plazo.
  Para que el fork tenga éxito, necesita un apoyo amplio y, al final, debe atraer no solo a unos pocos contribuidores prolíficos, sino a una porción cercana a la mayoría de la comunidad de D.
  De lo contrario, el fork fracasará, y la atención del proyecto original quedará aún más fragmentada, perdiendo incluso la viabilidad que le quedaba.
  Además, se necesita la capacidad y la voluntad de mantenerlo durante décadas.

• Parece que publicaron una actualización: https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.h... y parece que recibió algo de atención.
  Personalmente, habría sido más divertido llamarlo Died.
  Permitiría frases geniales como “It never Died”, también dejaría claro que es un fork y, si más adelante hiciera falta, daría margen para llevar el lenguaje en una nueva dirección.
  OpenD da la impresión de compatibilidad total.
  Claro que no tengo ningún interés directo en esto; les deseo lo mejor.

• Hay un hilo grande sobre este tema en el foro de D: https://forum.dlang.org/thread/[e-mail]...

  • El hilo grande señalado aquí lo iniciaron quienes están impulsando el fork —hasta ahora, dos personas—, y también contiene bastantes respuestas detalladas del lado de D que faltan en el texto de arriba.
    El texto original se centra sobre todo en quejas por conflictos personales, mientras que en ese enlace hay más discusión técnica.
    Viendo ese contenido, parece que quienes hacen el fork en realidad quieren otro lenguaje y están dispuestos a aceptar varios cambios que rompen la compatibilidad para lograrlo.

• Personalmente, si D se enfoca de lleno en el garbage collector, me confunde qué nicho de mercado está buscando
  Tampoco es que antes tuviera un nicho claro. En esencia era “un C++ 10% mejor”, y era difícil de vender porque no tenía una función estrella que lo diferenciara claramente
  Es probable que la mayoría se quede en C++ por el soporte existente, las bases de código y la base industrial, o use Rust para proyectos nuevos, o Zig si quiere simplicidad
  En especial después de C++20, ya existe algo así como un “C++ 10% mejor”
  Tampoco sé si enfocarse en el garbage collector ayude mucho
  Entonces competiría con C# y Java, que desde el inicio fueron lenguajes con garbage collection, seguros y concisos, pensados como sucesores de C++; no veo bien cómo podría competir con ellos a estas alturas
  En particular, C# tiene funciones de bajo nivel y unsafe bastante buenas, como punteros primitivos, control de tipos por referencia/por valor y control de la disposición en memoria, además de un sistema de tipos y reflexión decentes para ser un lenguaje viejo y orientado primero a objetos, y sigue incorporando funciones de la familia ML
  Sinceramente, la visión de D siempre me pareció confusa
  Leí documentación de funciones específicas del lenguaje como BetterC, modo safe y lifetimes, pero sintácticamente era difícil de leer y, aunque tenía muchos detalles, en general no estaba bien explicada
  Nunca sentí realmente una visión de diseño coherente ni un propósito para el lenguaje
  El autor menciona este problema, pero su visión tampoco parece mucho más clara
  Está bien que tengan algunos objetivos técnicos concretos de mediano plazo, pero no queda claro para qué existen esos objetivos
  Soy programador de Rust, así que es obvio qué usaría para un nuevo proyecto personal, pero si tuviera que elegir otra cosa, preferiría usar OCaml, C++ o incluso C#

  • Durante mucho tiempo D se promocionó como un C++ mejor, y eso estuvo mal por dos razones
    Primero, D es un reemplazo de C++, pero no es C++, y muchos desarrolladores de C++ se frustraron con esa diferencia
    Segundo, D puede hacer mucho más que ser un reemplazo de C++
    Puede usarse para scripts, como lenguaje de programación de propósito general y, en especial, para interoperabilidad con C mediante cosas como ImportC y BetterC
    Uno de los objetivos del fork es dejar de disculparse por el garbage collector
    La biblioteca estándar todavía tiene reference counting, unique pointer, etc.
    Si alguien quiere contribuir funciones que eviten el garbage collector, creo que serían aceptadas
    Pero en este fork probablemente sea menos común ver a Adam esforzándose demasiado por evitar el garbage collector al agregar nuevas funciones a la biblioteca estándar
    Él cree que el miedo al garbage collector está exagerado

• Durante los últimos 10 años hubo mucho que aprender sobre la gobernanza de los lenguajes de programación
  Si miramos los lenguajes emergentes y en evolución, ellos también sufrieron grandes choques o errores relacionados con la gobernanza
  Creo que ahora, al evaluar un lenguaje de programación, lo central es observar su gobernanza
  Hay que ver cómo dicen que operan, cómo operan realmente, qué resultados han tenido hasta ahora y cómo parece que será el futuro

  • Estoy de acuerdo en que es un tema importante, pero no creo que haya una respuesta satisfactoria
    La evolución de un lenguaje de programación es casi un ejercicio de gestión de complejidad, y al mismo tiempo tiene que equilibrar las necesidades de múltiples partes interesadas
    Casi todos los conflictos de gobernanza surgieron cuando un grupo de partes interesadas se quejó de requisitos que eran esenciales para otro grupo, y no siempre se puede satisfacer a ambos lados
    El async de Rust es un caso conocido de eso, y explica un diseño que funciona pero que, en general, no resulta satisfactorio
    Go es una rara excepción: el equipo central no tenía motivo para respetar a todas las partes interesadas y además tenía recursos y voluntad suficientes para no hacerlo, pero aun así surgieron algunos conflictos
  • La situación no mejoró
    El modelo de redacción de estándares de las décadas de 1960 a 1980 era mucho mejor, y además limitaba las peleas políticas a periodos cortos

• No veo bien cuál sería el lado negativo de que existan varias implementaciones de compilador
  Personalmente, creo que esa es una de las principales razones por las que C se difundió tanto
  Los compiladores pueden explorar direcciones distintas, y las extensiones del lenguaje que demuestran su valor terminan siendo adoptadas por otras implementaciones; a veces incluso llegan al estándar sin quedar demasiado desfiguradas durante el proceso de consenso del comité

  • Me confunde, porque pensaba que ya había unas 3
    Al menos creía que había 2 implementaciones: una del lado de gcc y otra de dlang