最近我一直在用C编写一些新的（“ greenfield ”）代码。我对此感到有点傻：如果您想要金属级性能并且不受过去工程决策的限制，那么您不应该使用Rust吗？还是去？ JVM上的东西？甚至C++ ？为什么要使用一种因记忆不安全和鼻恶魔而臭名昭著的 50 岁语言？
在这种情况下，有几件事非常适合 C：
-
我在数据繁重的情况下进行原型设计，以正确的方式迭代解决各种问题。通常我会使用Python进行原型设计，我在这里使用了很多。然而，在许多情况下，我需要在大量数据上快速运行我的代码，看看它在实践中是如何工作的，而我的 Python 实现通常太慢了。
-
我正在实现计算上直接的算法： Trie来计算唯一的固定长度子字符串（代码），或者通过多个进程写入一大块共享内存并接受冲突（代码）来近似先前的算法。如果我需要库支持或有大量棘手的逻辑，我会使用不同的工具。
-
我正在处理非常简单的格式：基本上只是长字符串
[ACGT]*。这使两个合规的代码规则保持一致。我不想使用 C 进行任何棘手的解析，除非它是沙盒的，而且我对沙盒设置非常有信心。 -
我主要靠自己解决这组问题，所以我应该选择能够最快取得进展的工具。如果我的代码有点奇怪，现在这并不重要。一旦我更好地掌握了我们将如何以计算方式解决这个问题，用现代语言重写可能是有意义的，这将更安全、更易读。
这里最大的风险是原型代码将成为生产代码，总会有比重写更紧迫的事情，而且在我们系统的核心，我们有一大段代码是用一种不安全的语言编写的，文档记录很差，阅读起来很混乱。这可能是反对用 C 语言开始任何东西的最有力论据，即使是原型设计也是如此。虽然我不能完全承诺确保不会发生这种情况，但我会睁大眼睛去做这件事。而且我至少会承诺认真记录任何正在成为生产代码的东西。
这是一种不同寻常的因素，如果几年前你问我是否会再次专业地编写 C 语言，更不用说选择用 C 语言开始一些东西了，我会说不。然而，在这种情况下，我认为这是正确的选择。
（我的节奏舞台设置的大部分，包括MIDI 路由和口哨控制的合成器也都在 C 中，尽管那里是为了最大限度地减少延迟而不是最大限度地提高吞吐量。因为那是我为了好玩而做的愚蠢的事情，我对此不那么奇怪.)