OpenD, a D language fork that is open to your contributions
A new community-led fork of the D programming language, dubbed OpenD, is prompting debate over governance, technical direction, and whether D can still carve out a viable niche in a world dominated by C++, Rust, Go, C# and Java. Commenters cite years of frustration with slow or dismissive leadership, unresolved design schisms (especially around garbage collection and lifetimes), and a weak ecosystem as reasons D lost momentum despite strong technical ideas. Many see the fork as a last chance to revitalize D by embracing the GC and loosening the gatekeeping on contributions, while others doubt it can overcome fragmentation or compete with better-funded, more widely adopted languages.
Scope of the Fork (“OpenD”)
- Fork is framed as a response to slow and difficult upstream decision-making, especially around language changes and contributions.
- Some see it as a “Tango 2.0” repeat and doubt it will change much; others hope it’s the only way to “save” D by rebooting governance.
- One concrete example: disagreement over string interpolation proposals, where the fork already shipped an alternative to the upstream design.
Naming and Identity
- Many joke-name proposals (e.g., punning on “D”, “open”, “free”), with frequent comments that “OpenD” is bland and suggests compatibility it might not maintain.
- Several suggest dropping the D name entirely to signal a real break, but others see value in leveraging D’s existing brand and tooling.
Governance and Leadership Critique
- Long-running dissatisfaction with language leadership: perceived ego, dismissiveness, resistance to outside ideas, and difficulty getting patches merged.
- Others counter that language designers must say “no” often and that leadership has been broadly civil under persistent criticism.
- Governance is highlighted as a key criterion when choosing languages; BDFL-style control is seen as both clarifying and risky, depending on taste.
Technical Direction: GC, Systems Programming, and Niche
- Major fault line: garbage collection.
- One camp: GC by default is a strength (productivity, easier CTFE); trying to appease
@nogcusers has imposed high costs for limited benefit. - Opposing camp: GC presence inherently limits D as a C/C++ replacement and puts it against stronger GC ecosystems (C#, Java, Go); optional GC is called a design dead-end.
- One camp: GC by default is a strength (productivity, easier CTFE); trying to appease
- Some argue D’s GC is technically outdated; if GC is embraced, it must be significantly improved.
- Others see D’s true niche as “better C/C++” via betterC, allocators, native code, and simpler syntax, making a GC-centric fork strategically puzzling.
Ecosystem, Tooling, and Community Health
- Repeated complaints: weak library ecosystem, poor or uneven IDE support, and especially rough beginner experience on Windows.
- Several note that languages like Rust and Go succeeded by building strong ecosystems and batteries-included tooling, not just better core language features.
- Some want D to focus on cohesive, practical standard libraries and “shipping real apps,” modeling Go’s approach.
Historical Context and Comparisons
- Many feel D had an early technical lead but lost it as C++11+, Go, Rust, Nim, Zig, C#, and others incorporated similar ideas.
- Forks in other ecosystems (LibreOffice, MariaDB, Nextcloud, Jenkins, Chromium/WebKit, X.Org, etc.) are cited as proof that forks can succeed, but only with broad community buy-in and long-term commitment.