Python remains the default language for much of scientific computing even as researchers keep paying the same tax: write the idea in Python, then move the hot path into C++, Rust, or another faster language when the code has to run at scale.
Wired writer and programmer Sheon Han framed that split as the modern “two-language problem,” a term used in scientific computing for the gap between comfortable prototyping and production-grade speed. His example is familiar to anyone who has waited on a notebook cell while pretending the cluster is the problem. Python is approachable and has a thick ecosystem. It is also slow enough that performance-critical work often leaves Python proper.
Julia was created in 2012 by four computer scientists with mathematics-heavy backgrounds to attack that trade-off directly. In the project’s launch essay, “Why We Created Julia,” the creators said they wanted an open source language with a permissive license that could be easy to learn while still satisfying advanced programmers. Their bet was that scientists should not need one language for expressing the model and another for making it finish before lunch.
The old problem has older roots
Han ties Julia’s ambition to an earlier programming-language fight. Kenneth Iverson won the Turing Award for APL, a language that began as a notation system intended to bring mathematical expression and computation closer together. APL was introduced 60 years before 2026, according to Han, and its compact symbols let programmers express array-oriented operations with the density of equations.
APL did not become a universal programming language, but Han argues that it mattered because it showed how notation can change what programmers can think and write. He points to Iverson’s 1979 Turing lecture, “Notation as a Tool of Thought,” and to Alfred North Whitehead’s observation that good notation frees the mind from unnecessary work.
Julia makes a related promise for the current era: write code that looks and feels suitable for scientists, then run it fast enough to avoid a rewrite. Han reports that Julia users at JuliaCon have described MATLAB-to-Julia rewrites with 60-fold speedups. He also cites benchmarks in which Julia code runs 10 to 1,000 times faster than Python. Benchmarks are benchmarks, so bring salt, a profiler, and the actual workload.
Python’s moat is not just syntax
Julia’s problem is adoption. Han notes that Julia does not appear on Stack Overflow’s annual chart of the most popular programming languages. Python, by contrast, has years of libraries, documentation, package habits, tutorials, glue code, and institutional muscle behind it. That kind of ecosystem is tedious to discuss and brutal to compete with.
Han also points to the lack of a large corporate sponsor pushing Julia into a dominant platform role. He compares that with Objective-C, which Apple made central to iOS development, and Kotlin, which Google backed for Android. Julia has not received the same Big Tech shove.
That has not made it irrelevant. Han says Julia is used at ASML, CERN, and NASA, and in work tied to drug discovery and advanced machine learning. The language’s user base leans academic, he writes, with scientists forming a large part of the community.
Han’s conclusion is measured: Julia may stay smaller than Python while still succeeding at the jobs it was built for. He is also skeptical that any one language can erase the two-language split across software. Game engines often pair C++ cores with Lua scripting. Server teams may use Python, Ruby, or JavaScript for convenience and Go or Rust when performance matters. Frontend attempts with Go or Rust have not displaced the web’s usual tools, according to Han.
Julia’s pitch is therefore less a coronation than a standing challenge. It asks whether scientific programmers can get speed and expressive code in one place. Python’s answer, for now, is a large pile of working libraries and a shrug.
This story draws on original reporting from WIRED.
