为何C语言的替代品难以成功
The case against a C alternative (2022)
我正在开发C3，试图成为C语言的替代品，但现实很骨感。C语言不仅是一门语言，更是一个成熟的工具链生态，从静态分析到内存检测，工具丰富且稳定。新语言面临诸多不确定性：语义可能变更、维护者可能消失，且缺乏经验丰富的开发者。更重要的是，C的ABI是互操作性的标准，新语言若无法无缝调用C代码，将寸步难行。所谓的“更好语法”或“更高生产力”往往只是主观感受，对企业而言，真正的价值在于能否带来独特的杀手级功能，像Java当年那样提供无可替代的优势。如果没有这样的独特卖点，仅仅因为“更好”而放弃C，对企业来说风险远大于收益。
除非替代品拥有C语言无法企及的重要独特功能或产品，否则几乎没有理由放弃C。
HN 评论区
77- friendzis
这篇文章的核心论点似乎有点“鸡生蛋，蛋生鸡”的味道。
> 4. 缺乏有经验的开发者
好吧，用 C 语言时，你需要的不仅是“有经验的开发者”，而是“精通 C 语言的有经验的开发者”。你可以写出能编译通过的 C 代码，但它可能千奇百怪地错误，而且通常是那种很隐蔽的错误。任何能协助开发者写出正确代码，或者直接拒绝编译错误代码的新语言（这里暗示的是 Rust），都能在一定程度上打破这个僵局。
> 如果你想针对某些冷门平台，那通常意味着你默认要用 C。
有些（大多数？）冷门平台确实提供了 GCC 的分支版本。随着 LLVM 前端越来越普及，这一点的重要性正在降低。无论是否有 C 的继任者，这个特定的“鸡生蛋”问题都在被打破。
> 任何 C 的替代品都被期望在性能上与 C 持平。问题是 C 几乎没有检查机制，所以任何在竞争语言中加入的安全检查都会带来运行时开销，而这往往是不可接受的。这导致了一种策略：只在“安全模式”下进行检查，而“快速模式”则和 C 一样“不安全”。
这个论点本身是循环论证的。确实存在一些场景，你绝对需要“汇编语言的宏系统”来搞一些奇奇怪怪的把戏，但通常这只是整个项目中很小的一部分。不安全模式正是为了解决这一小部分需求而存在的。这个论点的读起来像是：因为你项目的某些小地方需要类 C 语言，所以整个项目都得用类 C 语言。
> 3. 程序员生产力
整个论点奇怪地聚焦于 […]
- leni536
在我看来，C 语言的价值在于其互操作性。
有没有一种具备 ABI 稳定性的现代语言能替代 C 来实现这一点？也就是说，你可以用 C API 封装任何东西，并确保它能轻松地从任何其他语言中调用？
- palata
从某种意义上说，我也有罪，我启动了一个名为 C+ 的新编程语言，我设定的支柱之一就是它不应该成为 C（或任何其他语言）的替代品。事实上，它使用 Clang 作为编译器。文章中的大多数观点仍然成立，但我希望这不会阻止人们在这个领域提出新想法并真正付诸实施。你不必成为下一个“大事件”才能变得出色。