OpenD，一个欢迎你贡献的 D 语言分支

原文 ↗ Hacker News 讨论 ↗

一个由社区主导的新 D 语言分支 OpenD 引发了关于治理、技术方向以及在由 C++、Rust、Go、C# 和 Java 主导的世界里，D 是否仍能找到可行利基的讨论。评论者提到，多年来人们对缓慢或轻慢的领导层、未解决的设计分歧（尤其围绕垃圾回收和生命周期）以及薄弱生态的挫败感，这些都是 D 尽管有很强的技术想法却失去势头的原因。许多人把这个分支视为振兴 D 的最后机会，认为应当拥抱 GC 并放宽对贡献的把关；也有人怀疑它能否克服碎片化，或与资金更充足、采用更广泛的语言竞争。

分支范围（“OpenD”）

  • 这个分支被定位为对上游决策缓慢且困难的回应，尤其是在语言变更和贡献方面。
  • 有人把它看作又一次“Tango 2.0”式重演，并怀疑它不会改变多少；也有人希望它是通过重启治理来“拯救” D 的唯一办法。
  • 一个具体例子：围绕字符串插值提案的分歧，其中这个分支已经发布了与上游设计不同的替代方案。

命名与身份

  • 有很多玩笑式命名提议（例如围绕“D”“open”“free”做双关），并且经常有人评论说“OpenD”很平淡，而且暗示了它未必能维持的兼容性。
  • 一些人建议干脆去掉 D 这个名字，以表明真正的切割；但也有人认为，利用 D 现有的品牌和工具链是有价值的。

治理与领导力批评

  • 对语言领导层长期不满：被认为自负、轻慢、抗拒外来想法，而且补丁很难合并。
  • 也有人反驳说，语言设计者必须经常说“不”，而在持续批评下，领导层总体上一直是文明的。
  • 治理被强调为选择语言时的关键标准；BDFL 式控制被视为既能让方向更清晰，也可能很危险，取决于个人偏好。

技术方向：GC、系统编程与利基定位

  • 一个主要分歧点：垃圾回收。
    • 一派认为：默认 GC 是优势（生产力更高、CTFE 更容易）；为了迎合 @nogc 用户而付出的高昂代价，换来的收益有限。
    • 另一派认为：GC 的存在本质上限制了 D 作为 C/C++ 替代品的定位，并使其要面对更强的 GC 生态（C#、Java、Go）；可选 GC 被称为设计死胡同。
  • 有人认为 D 的 GC 在技术上已经过时；如果要拥抱 GC，就必须显著改进它。
  • 也有人认为 D 的真正利基是通过 betterC、分配器、本机代码和更简单的语法，成为“更好的 C/C++”；因此，一个以 GC 为中心的分支在战略上显得令人困惑。

生态、工具与社区健康

  • 反复出现的抱怨包括：库生态薄弱、IDE 支持差或不均衡，以及在 Windows 上尤其糟糕的入门体验。
  • 一些人指出，Rust 和 Go 等语言之所以成功，是因为它们建立了强大的生态和“开箱即用”的工具，而不只是更好的核心语言特性。
  • 有人希望 D 关注一致、实用的标准库，并“交付真正的应用”，以 Go 的方式作为参照。

历史背景与比较

  • 许多人认为，D 早期在技术上领先，但随着 C++11+、Go、Rust、Nim、Zig、C# 等将类似想法纳入自身，D 逐渐失去了优势。
  • 其他生态中的分支（LibreOffice、MariaDB、Nextcloud、Jenkins、Chromium/WebKit、X.Org 等）被拿来作为证据，说明分支确实可以成功，但前提是要有广泛的社区认同和长期投入。