Python 太慢了。Julia 能解决两语言问题吗？

# Python 这么慢。Julia 能解决两语言问题吗？ 来源：https://www.wired.com/story/python-is-so-slow-can-julia-solve-the-two-language-problem/ 作为一种类型，“获奖感言”往往只是形式主义和陈词滥调。但这条规则至少有一个迷人的例外——顶尖计算机科学家在图灵奖（https://amturing.acm.org/）颁奖之际发表的演讲。 有些读起来像宣言：约翰·巴克斯的《编程能否摆脱冯·诺依曼风格？》（1977）（https://dl.acm.org/doi/10.1145/359576.359579）激励了一种新范式，催生了像 Haskell 这样的函数式语言。另一些则是警告：在《对信任的反思》（1984）（https://dl.acm.org/doi/10.1145/1283920.1283940）中，肯·汤普森演示了后门编译器的危险，可能防止了大量安全漏洞。艾兹格·迪杰斯特拉在《谦卑的程序员》（1972）（https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html）中敦促同行警惕聪明才智，承认“人类心智的内在局限性”。 就我们而言，考虑一下肯尼斯·艾弗森 1979 年那场令人振奋的演讲《符号作为思维工具》（https://dl.acm.org/doi/10.1145/1283920.1283935）。他演示了数学符号不只是一个方便的速记——二氧化碳用 CO2，3888 用 MMMDCCCLXXXVIII——它们还能让新见解易于发现。正如数学家阿尔弗雷德·诺思·怀特海曾经说过的：“通过减轻大脑所有不必要的工作，一个好的符号能让大脑解放出来，专注于更高级的问题。” 艾弗森因 APL 赢得图灵奖，APL 是一种看起来古怪的编程语言，最初是作为连接不同语言的符号系统而诞生的。在科学计算的早期，程序员必须用一种语言思考（数学符号），然后用另一种语言编程（例如 Fortran）。APL 的设计目标是让笨拙的操作能像方程式一样紧凑地写出来——代码行压缩成几个像 **+** 或 **×** 这样的符号。APL 最终影响力大于实际采用率，但没关系：它证明了两种语言可以融合成一种。 2026 年标志着 APL 诞生 60 周年，一种新型的两语言问题困扰着科学计算领域。主导编程语言是 Python（https://www.wired.com/story/how-i-became-a-python-programmer-and-distanced-myself-from-the-machine/），但它的统治并非像强大的征服者，更像一位老态龙钟的国王。换句话说，Python 慢得可怕——这个缺点即使是最热心的捍卫者也不会否认。 这就引出了两语言问题：研究人员用缓慢但友好的 Python 做原型，但对于性能关键部分，需要重写为更快但不太友好的语言，如 C++ 或 Rust。这个限制无法通过组建一支 AI 编码代理大军来解决，因为无论你如何优化一门慢语言，更快的语言都会胜过它。 这种二元权衡在其他领域也存在。你可以说，例如，建筑行业有一个两材料问题。木材是一种可塑的材料，适合用来搭建结构原型——即使是业余爱好者也能锯钉出一个功能性的建筑。但它不适合建造摩天大楼。这就引出了一个显而易见的问题：如果有一种像木材一样可操作但像钢铁一样坚固的材料呢？如果有一种像 Python 一样好用但像 C 一样快的语言呢？ 2012 年，四位有着扎实数学背景的计算机科学家联手应对现代的两语言问题。在一篇题为《为什么我们创造了 Julia》（https://julialang.org/blog/2012/02/why-we-created-julia/）的短文中，他们说他们启动这个项目是因为“我们很贪婪”。他们的文字以对编程语言的情书开头： *我们是强大的 MATLAB 用户。我们中的一些人是 Lisp 黑客。一些人是 Pythonistas，另一些是 Rubyists，还有一些是 Perl 黑客……我们生成的 R 图比任何理智的人应该生成的都要多。C 是我们荒岛编程语言。* 但他们写道，这些语言中的每一种“都完美适用于某些方面的工作，而在其他方面则糟糕透顶。”他们贪婪地想要“一种开源的、具有宽松许可证的语言……一种简单易懂，同时又能让最严肃的黑客满意的语言。”Julia 将成为统一所有语言的那一种。 我第一次遇见 Julia 是在 2017 年——在其语法稳定前一年——当时我参加了神经科学家 Sebastian Seung 的讲座，他正使用 Julia 来绘制连接组，即大脑中神经通路的完整图谱。我的第一印象是其令人愉悦、可爱的名字，它背离了该领域常见的笨拙命名法：不优雅的（PL/I）、难看的（Erlang）、排版笨重的（C++）以及字面上病理性的（MUMPS——如果你能相信的话，它构成了美国医疗系统的骨干）。 我还能看出 Julia 的设计投入了深思。在研究了其他语言落入的许多陷阱之后，创造者们从不同语言中整合了绝妙的想法——这证明了在开始创建一种新语言这样精细的事业之前，必须进行仔细的观察。 截至 2026 年，Julia 已经吸引了一个稳重的成年人社区——这可不是许多语言社区能说的。语言爱好者是一个情绪化、喧闹的群体（许多友谊因为对语法的不同看法而破裂），但 Julia 社区尚未被任何重大戏剧所动摇。它偏向学术界，吸引的科学家多于黑客。但与其他也被学术界使用的语言不同，Julia 不会过于奇幻（像 Haskell（https://www.wired.com/story/inside-the-cult-of-the-haskell-programmer/）那样），也不吸引崇拜者（同样像 Haskell），也不参与智力博弈（比如，像 Haskell 那样）。在年度 JuliaCon 上，你会听到关于将 MATLAB 代码重写为 Julia（https://pretalx.com/juliacon2021/talk/WT8PHT）并获得 60 倍速度提升的胜利故事。根据一些基准测试，Julia 代码运行速度比 Python 快 10 到 1000 倍。 但你不会在 Stack Overflow 的年度调查图表（https://survey.stackoverflow.co/2025/technology#most-popular-technologies）中找到 Julia 在最受欢迎语言之列。它最终没有取代 Python——甚至远远没有。为什么？哪里出错了？ 首先，正如人类语言依赖于用其编写的文本语料库一样，编程语言的好坏取决于其生态系统和工具链。Python 的生态系统太强大了，无法撼动。其次，Julia 没有被大科技公司采用。过去，当一种小众语言从默默无闻中脱颖而出并崭露头角时，得益于这种企业赞助：苹果的 Objective-C 用于 iOS 开发，谷歌的 Kotlin 用于 Android 开发。 但第三，这是我的答案：没有什么出错了。Julia 是一种小众语言，就其所做的事情而言，它已经相当成功了。Julia 很可能会继续存在，虽然小众但备受喜爱。它被用于像 ASML（https://pretalx.com/juliacon-2022/talk/GUQBSE）、CERN（https://link.springer.com/article/10.1007/s41781-023-00104-x）和 NASA（https://juliahub.com/videos/modeling-spacecraft-separation-dynamics-in-julia-for-nasa）这样的机构进行赫拉克勒斯式的工作，并用于像药物发现（https://juliahub.com/case-studies/pfizer）和高级机器学习（https://sciml.ai/）这样的严肃事业。 即使 Julia 某天取代了 Python，我也不相信它能够解决两语言问题——或者说没有任何语言能够解决。虽然这个问题在科学计算中经常被提及，但它存在于每个软件领域。在游戏中，引擎用 C++ 编写，但脚本用 Lua。在后端服务器中，有各种更简单的语言——Python、Ruby、JavaScript——但当需要真正性能时，工作由 Go 或 Rust 完成。相反，用 Go 或 Rust 进行前端开发的勇敢尝试完全失败了。 但我是谁，有什么资格说我们会永远困在这里？也许有一天，像艾弗森一样有洞察力的人会找出如何一劳永逸地弥合这个差距。到那时，一定要收听他们的图灵奖演讲。 --- *这是三部分系列“机器可读”（https://www.wired.com/tag/machine-readable/）的第二部分，关注支持 AI 的语言。*