Python Is So Slow. Can Julia Solve the Two-Language Problem?

Python 太慢了。Julia 能解决“双语言问题”吗？

As a genre, the “award acceptance lecture” is little more than a formality and a banality. But there is at least one charming exception to this rule—the talks given by the foremost computer scientists on the occasion of their Turing Awards. 作为一种体裁，“获奖感言”往往不过是流于形式的陈词滥调。但这一规则至少有一个迷人的例外——顶尖计算机科学家在获得图灵奖时发表的演讲。

Some read like manifestos: John Backus’ “Can Programming Be Liberated From the von Neumann Style?” (1977) inspired a new paradigm that begat functional languages like Haskell. Others are warnings: In his “Reflections on Trusting Trust” (1984), Ken Thompson demonstrated the peril of backdoored compilers, likely preventing scads of security vulnerabilities. Edsger Dijkstra, in “The Humble Programmer” (1972), urged his ilk to be wary of cleverness and acknowledge “the intrinsic limitations of the human mind.” 有些演讲读起来像宣言：约翰·巴科斯（John Backus）在 1977 年的《编程能从冯·诺依曼风格中解放出来吗？》启发了一种新的范式，催生了像 Haskell 这样的函数式语言。另一些则是警示：肯·汤普逊（Ken Thompson）在 1984 年的《对信任的反思》中展示了后门编译器的危险，可能因此预防了大量的安全漏洞。艾兹格·迪杰斯特拉（Edsger Dijkstra）在 1972 年的《谦卑的程序员》中，敦促同行警惕小聪明，并承认“人类思维固有的局限性”。

For our purposes, consider Kenneth Iverson’s heady 1979 lecture, “Notation as a Tool of Thought.” In it, he demonstrated that mathematical notations aren’t just convenient shorthand—CO2 for carbon dioxide, 3,888 for MMMDCCCLXXXVIII—they also make new insights readily discoverable. As the mathematician Alfred North Whitehead once put it: “By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems.” 就本文而言，不妨看看肯尼斯·艾弗森（Kenneth Iverson）1979 年那场令人振奋的演讲《作为思维工具的符号》。他在演讲中证明，数学符号不仅仅是方便的速记（例如用 CO2 表示二氧化碳，用 3,888 表示 MMMDCCCLXXXVIII），它们还能让人们更容易发现新的见解。正如数学家阿尔弗雷德·诺思·怀特海（Alfred North Whitehead）曾经说过的：“通过减轻大脑所有不必要的工作，好的符号系统能让大脑腾出精力去专注于更高级的问题。”

Iverson won his Turing Award for APL, a spooky-looking programming language that began its life as a system of notation for bridging between languages. In the early days of scientific computing, programmers had to think in one language (mathematical notation) but then program in another (e.g., Fortran). APL was designed so that unwieldy operations could be written as compactly as equations—lines of code collapsed into a couple of symbols like + or ×. APL turned out to be more influential than adopted, but no matter: It showed that two languages could be fused into one. 艾弗森凭借 APL 赢得了图灵奖。这是一种看起来有些诡异的编程语言，最初是作为一种连接不同语言的符号系统而诞生的。在科学计算的早期，程序员必须用一种语言（数学符号）思考，然后用另一种语言（如 Fortran）编程。APL 的设计初衷是将繁琐的操作写得像方程一样简洁——原本多行的代码被压缩成几个像 + 或 × 这样的符号。APL 的影响力最终大于其实际采用率，但这并不重要：它证明了两种语言是可以融合为一的。

The year 2026 marks 60 years since the introduction of APL, and a new kind of two-language problem bedevils the field of scientific computing. The ruling programming language is Python, but it reigns not as a muscular conqueror so much as a doddering king. Python, in other words, is terribly slow—a flaw that even its most ardent defenders would not deny. 2026 年是 APL 诞生 60 周年，而一种新型的“双语言问题”正困扰着科学计算领域。目前统治地位的编程语言是 Python，但它与其说是一位强壮的征服者，不如说是一位老态龙钟的君主。换句话说，Python 慢得可怕——即使是它最狂热的拥护者也无法否认这一缺陷。

Hence the two-language problem: Researchers prototype in slow, friendly Python but, for performance-critical parts, rewrite in faster, less friendly languages like C++ or Rust. This limitation can’t be solved by spinning up a platoon of AI coding agents, because no matter how much you optimize a slow language, a faster one will outperform it. 这就是所谓的“双语言问题”：研究人员用缓慢但友好的 Python 进行原型设计，但对于性能关键的部分，则必须用 C++ 或 Rust 等更快但不太友好的语言重写。这种局限性无法通过部署一大批 AI 编程代理来解决，因为无论你如何优化一种缓慢的语言，更快的语言总会胜过它。

These binary trade-offs exist in other domains. You could say that construction, for instance, has a two-material problem. Wood is a pliable material for prototyping a structure—even an amateur can saw and nail together a functional building. But it’s no good for erecting a skyscraper. This raises an obvious question: What if there were a material as manipulable as wood but as strong as steel? What if there were a language as ergonomic as Python but as fast as C? 这种二元权衡在其他领域也存在。例如，建筑业可以说存在“双材料问题”。木材是一种用于构建结构原型的柔性材料——即使是业余爱好者也能锯开并钉出一个功能性的建筑。但它不适合建造摩天大楼。这引出了一个显而易见的问题：如果有一种材料既像木材一样易于操作，又像钢铁一样坚固，会怎样？如果有一种语言既像 Python 一样符合人体工程学，又像 C 一样快，会怎样？

In 2012, four computer scientists with strong mathematical bona fides came together to address the modern-day two-language problem. In a short essay called “Why We Created Julia,” they said they took up the project “because we are greedy.” Their text begins like a valentine to programming languages: 2012 年，四位拥有深厚数学背景的计算机科学家聚在一起，试图解决现代的“双语言问题”。在一篇名为《我们为何创造 Julia》的短文中，他们表示启动这个项目“是因为我们贪婪”。文章的开头就像一封写给编程语言的情书：

We are power Matlab users. Some of us are Lisp hackers. Some are Pythonistas, others Rubyists, still others Perl hackers … We’ve generated more R plots than any sane person should. C is our desert island programming language. 我们是 Matlab 的重度用户。我们中有些人是 Lisp 黑客。有些人是 Python 拥趸，有些人是 Ruby 开发者，还有些人是 Perl 黑客……我们生成的 R 语言图表比任何正常人应该做的都要多。C 是我们流落荒岛时唯一想带的编程语言。

But every one of these languages, they wrote, “is perfect for some aspects of the work and terrible for others.” Greedy as they were, they wanted “a language that’s open source, with a liberal license … Something that is dirt simple to learn, yet keeps the most serious hackers happy.” Julia would be the one language to unite them all. 但他们写道，这些语言中的每一种“在某些方面表现完美，但在其他方面却糟糕透顶”。出于“贪婪”，他们想要“一种开源的、拥有宽松许可证的语言……一种学起来极其简单，却又能让最严肃的黑客感到满意的语言。”Julia 将成为统一所有这些语言的唯一语言。

I first encountered Julia by happenstance in 2017—a year before its syntax stabilized—when I attended lectures by Sebastian Seung, a neuroscientist who was using it to map connectomes, the complete map of neural pathways in the brain. My first impression was of its delightful, winsome name, which defied the clumsy nomenclature common in the field: the inelegant (PL/I), the ugly (Erlang), the typographically ungainly (C++), and the literally pathological (MUMPS—which, if you can believe it, forms the backbone of the American health care system). 我第一次偶然接触到 Julia 是在 2017 年——也就是其语法稳定前的一年——当时我参加了神经科学家塞巴斯蒂安·承（Sebastian Seung）的讲座，他当时正在使用 Julia 来绘制连接组（大脑神经通路的完整图谱）。我的第一印象是它那令人愉悦、迷人的名字，这与该领域常见的笨拙命名形成了鲜明对比：不优雅的（PL/I）、丑陋的（Erlang）、排版上难看的（C++），以及字面上就有“病态”含义的（MUMPS——如果你敢相信的话，它竟然构成了美国医疗保健系统的骨干）。

I could also see that serious thought had gone into designing Julia. After studying the many pitfalls other languages had fallen into, the creators marshaled neat ideas from different languages—a testament to the fact that careful observation must come before embarking on so fine an enterprise as creating a new one. 我还能看出，Julia 的设计经过了深思熟虑。在研究了其他语言陷入的许多陷阱后，创造者们汇集了来自不同语言的精妙构思——这证明了在着手创造新语言这样伟大的事业之前，必须进行仔细的观察。

As of 2026, Julia has come to attract a sober community of grown-ups—which can’t be said of many language communities. Language nerds are an emotional, clamorous bunch (many a friendship has been broken over a difference of opinion on syntax), but the Julia community has yet to be convulsed by any major drama. It leans academic, drawing scientists more than hackers. But unlike other languages also used by academics, Julia doesn’t get too fanciful (like Haskell), nor does it attract worshipful fans (also like Haskell) or engage in intellectual gamesmanship (like, say, Haskell). At the annual Julia-Con, you’ll hear triumphant stories of rewriting MATLAB code in Julia and gaining 60X speedups. By some benchmarks, Julia code can run 10X to 1,000X faster than Python. 截至 2026 年，Julia 已经吸引了一个冷静、成熟的社区——这一点在许多语言社区中是很难得的。语言极客们通常是一群情绪化、吵闹的人（许多友谊都因为对语法的意见分歧而破裂），但 Julia 社区至今尚未被任何重大闹剧所困扰。它偏向学术界，吸引的科学家多于黑客。但与其他同样被学者使用的语言不同，Julia 不会变得过于天马行空（像 Haskell 那样），也不会吸引狂热的崇拜者（也像 Haskell 那样），或者沉迷于智力游戏（比如 Haskell）。在每年的 Julia-Con 大会上，你会听到用 Julia 重写 MATLAB 代码并获得 60 倍速度提升的成功故事。根据一些基准测试，Julia 代码的运行速度可以比 Python 快 10 到 1000 倍。

But you won’t find Julia on Stack Overflow’s annual survey chart of the most popular languages. It didn’t replace Python, in the end—not even close. Why not? What went wrong? 但你在 Stack Overflow 的年度最受欢迎语言调查表中找不到 Julia。最终，它并没有取代 Python——甚至相去甚远。为什么呢？出了什么问题？

First, just as a human language depends on the corpus of texts written in it, a programming language is only as good as its ecosystem and tooling. Python’s is far too robust to dislodge. Second, Julia has not been adopted by Big Tech. In the past, when a minor language was plucked from obscurity and rose to prominence, it was thanks to this k 首先，正如人类语言依赖于用它写成的文本语料库一样，编程语言的好坏取决于其生态系统和工具。Python 的生态系统太强大了，难以撼动。其次，Julia 尚未被大型科技公司采用。在过去，当一门小众语言从默默无闻走向崛起时，往往归功于……