在过去几年里，我越来越多地被问到这样的问题：人工智能是否会从新类型的编程语言中受益？我的回答一直是“可能不会”，而且，至少到目前为止，这个答案似乎是准确的：人工智能现在能够用几乎任何我或你能想到的编程语言生成大量代码。现在，随着技术的进步及其特征的逐渐清晰，我的回答发生了变化。根据我的经验，人工智能——至少就目前而言——通常能够生成高质量的局部（例如，一个函数）代码块，但在需要对程序有全局理解的代码生成时往往会遇到困难。看到这一点最简单的方法就是频繁出现不必要的防御性检查：这些似乎是无害的，但可能会导致后来的读者认为代码中可以出现的状态数量呈指数增长，从而带来所有隐含的消极影响。也许这种挣扎很快会被克服，但如果没有的话，我们可能会再次寻求编程语言设计的帮助。我在这篇文章中的目的是不试图预测编程语言将要或甚至应该尝试解决这个问题的具体方式。相反，我想回答一个更基础的问题：我们是否有好的编程语言设计示例，可以让局部推理给予我们对意外全局特性的保证？背景 我从编程语言中获得了相当一部分的收入，因此我有动机来强调它们的重要性。然而，虽然我相信编程语言确实对我们的生产力和我们创造的软件的可靠性有一定的影响，但并没有太多证据表明它们产生了深远的改变。我并不是仅仅指“没有人能够做一个好的实验来证明存在差异”——尽管这是事实！而是，很多“好的”软件是在“坏的”语言中创建的，很多“坏的”软件是在“好的”语言中创建的。用特定的编程语言对这些结果的主要影响似乎不太可能。对此的最简单论证是，创建能满足用户所有需求、以可理解和可靠的方式运行的软件，比起掌握复杂的编程语言特性，更需要同理心。为了稍微更细致的观点，我之前尝试过表达我对软件本质的看法。这并不是说编程语言没有任何区别。对我来说，从汇编编程转向“高级”语言如 Python 和 C，我的生产力显著提高，并且我感到更有能力处理更大的软件项目。原因很简单：汇编语言让我必须处理许多底层细节，以至于我不断忘记更重要的高层次情况。我能创建的软件的差距是显著的。不幸的是，我逐渐意识到这种巨大的改进不太可能再现。我慢慢而笨拙地重新发明了弗雷德·布鲁克斯的“没有银弹”论点：过去软件生产力的许多重大提升来自消除人为的障碍，这些障碍使得偶然任务异常困难，例如，严重的硬件限制、尴尬的编程语言、缺少机器时间。如今软件工程师所做的工作中，有多少仍然是专注于偶然的，而不是本质的？除非这种偶然的活动超过所有努力的90%，否则将所有偶然活动缩减为零时间将无法带来数量级的改善。一个例外 这意味着当在特定背景下多年后，我经历了我编写的许多软件的另一种深刻的生产力变革时，我感到非常惊讶，以至于几乎没有注意到。当我最终注意到，并试图向其他人解释这种差异时，他们似乎也感到困惑。背景？用 Rust 进行多线程编程。这一经历也塑造了我对未来编程语言最佳方向的看法，因此我需要说服你，Rust 在让多线程编程变得更容易的方式中，存在着某种深刻之处。让我从一个具体的例子开始。我写的构建您当前正在阅读的网站的软件是作为正常的单线程代码编写的。因为我懒惰——而且我的网站不算特别大——所以每次运行时，整个网站都会重新构建。过了一段时间后，我发现软件重建网站所需的暂停时间足够长，以至于使得编辑某些页面（比如这篇文章！）变得效率低下。我迅速进行了一些单线程的优化，但这些还不够。我猜测如果我能将其重写为使用多线程，那么这些暂停时间将降到一个可接受的水平。在几乎任何其他编程语言中，将软件重写为使用多线程将是一项艰巨的任务。确实，我过去与多线程的经历让我知道我会立即遇到...