OpenD, un fork del lenguaje D abierto a tus contribuciones

Un nuevo fork de la comunidad del lenguaje de programación D, llamado OpenD, está suscitando debate sobre la gobernanza, la dirección técnica y si D aún puede labrarse un nicho viable en un mundo dominado por C++, Rust, Go, C# y Java. Los comentaristas citan años de frustración con un liderazgo lento o despectivo, divisiones de diseño no resueltas (especialmente en torno a la recolección de basura y los tiempos de vida) y un ecosistema débil como razones por las que D perdió impulso pese a contar con ideas técnicas sólidas. Muchos ven el fork como la última oportunidad de revitalizar D abrazando el GC y relajando el control sobre las contribuciones, mientras que otros dudan de que pueda superar la fragmentación o competir con lenguajes mejor financiados y más adoptados.

Alcance del fork (“OpenD”)

  • El fork se plantea como respuesta a una toma de decisiones upstream lenta y कठिनosa, especialmente en torno a los cambios del lenguaje y las contribuciones.
  • Algunos lo ven como una repetición de “Tango 2.0” y dudan de que vaya a cambiar mucho; otros esperan que sea la única forma de “salvar” D reiniciando la gobernanza.
  • Un ejemplo concreto: el desacuerdo sobre propuestas de interpolación de cadenas, donde el fork ya publicó una alternativa al diseño upstream.

Nombre e identidad

  • Abundan las propuestas de nombres en broma (por ejemplo, juegos de palabras con “D”, “open”, “free”), con comentarios frecuentes de que “OpenD” es soso y sugiere una compatibilidad que quizá no mantenga.
  • Varios sugieren abandonar por completo el nombre D para señalar una ruptura real, pero otros ven valor en aprovechar la marca y las herramientas ya existentes de D.

Críticas a la gobernanza y al liderazgo

  • Insatisfacción de larga data con el liderazgo del lenguaje: ego percibido, desdén, resistencia a ideas externas y dificultad para que se integren los parches.
  • Otros responden que los diseñadores de lenguajes deben decir “no” con frecuencia y que el liderazgo, en general, ha sido civil pese a las críticas persistentes.
  • La gobernanza se destaca como criterio clave al elegir lenguajes; el control al estilo BDFL se ve como algo a la vez clarificador y arriesgado, según el gusto de cada cual.

Dirección técnica: GC, programación de sistemas y nicho

  • Gran línea de fractura: la recolección de basura.
    • Un bando: el GC por defecto es una fortaleza (productividad, CTFE más fácil); intentar contentar a los usuarios de @nogc ha impuesto costes altos para un beneficio limitado.
    • Bando opuesto: la presencia de GC limita intrínsecamente a D como reemplazo de C/C++ y lo enfrenta a ecosistemas con GC más sólidos (C#, Java, Go); el GC opcional se califica de callejón sin salida de diseño.
  • Algunos sostienen que el GC de D está técnicamente anticuado; si se adopta el GC, debe mejorarse de forma significativa.
  • Otros ven el verdadero nicho de D como “mejor C/C++” mediante betterC, allocators, código nativo y una sintaxis más simple, por lo que un fork centrado en GC resulta estratégicamente desconcertante.

Ecosistema, herramientas y salud de la comunidad

  • Quejas repetidas: ecosistema de bibliotecas débil, soporte de IDE pobre o desigual y, especialmente, una experiencia inicial áspera en Windows.
  • Varios señalan que lenguajes como Rust y Go triunfaron construyendo ecosistemas sólidos y herramientas “baterías incluidas”, no solo mejores características del lenguaje base.
  • Algunos quieren que D se centre en bibliotecas estándar cohesionadas y prácticas, y en “lanzar aplicaciones reales”, siguiendo el enfoque de Go.

Contexto histórico y comparaciones

  • Muchos sienten que D llevaba ventaja técnica al principio, pero la perdió cuando C++11+, Go, Rust, Nim, Zig, C#, y otros incorporaron ideas similares.
  • Se citan forks en otros ecosistemas (LibreOffice, MariaDB, Nextcloud, Jenkins, Chromium/WebKit, X.Org, etc.) como prueba de que los forks pueden funcionar, pero solo con un amplio respaldo comunitario y compromiso a largo plazo.