The Unlikely, Quiet Success of Julia, the Language That Tried to Solve Programming’s Oldest Tradeoff

As a category, award acceptance speeches are rarely more than stilted formalities full of unmemorable platitudes. But there is one delightful, notable exception to this pattern: the acceptance lectures delivered by leading computer scientists when they receive the Turing Award, the field’s highest honor.

Some of these lectures read like bold intellectual manifestos: John Backus’s 1977 talk Can Programming Be Liberated From the von Neumann Style? sparked an entirely new programming paradigm that eventually gave rise to functional languages such as Haskell. Others act as prescient warnings: In his 1984 lecture Reflections on Trusting Trust, Ken Thompson laid bare the existential danger of backdoored compilers, a lesson that has likely prevented countless devastating security breaches decades later. Edsger Dijkstra, in his 1972 address The Humble Programmer, urged fellow programmers to guard against overvaluing clever code and to openly recognize “the intrinsic limitations of the human mind.”

For this discussion, let’s turn to Kenneth Iverson’s thought-provoking 1979 Turing lecture, Notation as a Tool of Thought. In that talk, Iverson argued that mathematical notation is far more than just a convenient shorthand—think CO₂ for carbon dioxide, or 3,888 instead of the clunky Roman numeral MMMDCCCLXXXVIII. Good notation, he showed, makes entirely new insights accessible to thinkers. As mathematician Alfred North Whitehead once observed: “By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems.”

Iverson earned his Turing Award for creating APL, an unusual-looking programming language that started out as a notation system designed to bridge the gap between human-written mathematical frameworks and machine code. In the early days of scientific computing, programmers had to conceptualize problems in one language (mathematical notation) then rewrite all their logic in a second, entirely different language for machines (such as Fortran). APL was built to let programmers write complex, unwieldy operations just as compactly as they would write mathematical equations, shrinking lines of verbose code down to just a handful of simple symbols, similar to + or ×. Though APL ended up being far more influential than it was widely adopted, it proved a core concept: two separate language layers could be fused into one unified system.

2026 marks 60 years since APL was first introduced, and today a new version of the two-language problem plagues modern scientific computing. Python is the undisputed dominant language in the field today, but it rules less like a powerful conqueror and more like an aging, out-of-shape monarch. Put simply: Python is notoriously slow, a flaw even its most passionate supporters do not attempt to deny.

This gives rise to the modern two-language problem: Researchers build and test prototypes in slow, easy-to-use Python, but for any parts of the code where performance is critical, they have to rewrite those sections in faster, far less user-friendly languages like C++ or Rust. Not even a fleet of AI coding assistants can solve this limitation: no matter how much you optimize an inherently slow language, a natively faster language will always outperform it.

This kind of binary tradeoff appears in plenty of other fields too. For example, you could think of construction as having a two-material problem. Wood is flexible and easy to work with when prototyping a structure—even an amateur can cut and nail wood together to build a functional small building. But it is completely unsuitable for building a skyscraper. This leads to an obvious question: What if there was a material as easy to shape as wood, but as strong as steel? What if there was a programming language as comfortable and user-friendly as Python, but as fast as C?

In 2012, four computer scientists with deep mathematical backgrounds teamed up to solve this modern two-language problem. In a short essay titled Why We Created Julia, they explained they started the project “because we are greedy.” The opening of their essay reads like a love letter to the diversity of programming languages:

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.

But every single one of these languages, they noted, “is perfect for some aspects of the work and terrible for others.” Greedy for something better, 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 that united all these desirable qualities into one.

I first stumbled on Julia by chance in 2017, a year before its syntax was finalized, when I attended a series of lectures by neuroscientist Sebastian Seung, who was using Julia to map connectomes—complete maps of neural pathways in the brain. My first impression was how charming and approachable its name was, a stark contrast to the clunky, awkward naming conventions so common in the field: the clunky PL/I, the unattractive Erlang, the typographically messy C++, and the outright bizarre MUMPS—which, incredibly enough, forms the core backbone of the United States healthcare system.

It was also clear that the creators of Julia put enormous intentional thought into its design. After studying the countless missteps other programming languages had made, the team pulled elegant, useful ideas from languages across the field—a reminder that careful observation of existing work is essential before launching a project as ambitious as building a new programming language.

As of 2026, Julia has attracted a thoughtful, level-headed community of users—a claim many other programming language communities cannot make. Programming language enthusiasts are often an impassioned, loud group (friendships have fractured over disagreements about basic syntax choices), but the Julia community has yet to be roiled by any major public drama. The community leans heavily academic, drawing more practicing scientists than hobbyist hackers. And unlike other popular languages among academics, Julia never veers into overly abstract academic fancy (like Haskell), nor does it attract the kind of cult-like, adoring fanbase (also like Haskell), nor does it lean into unnecessary intellectual one-upmanship (again, like Haskell).

At the annual JuliaCon conference, attendees regularly share success stories of rewriting old MATLAB code in Julia and seeing 60x speed improvements. By many performance benchmarks, Julia code runs between 10x and 1,000x faster than equivalent Python code. Yet you will not find Julia on Stack Overflow’s annual survey of the most popular programming languages. It never replaced Python, in the end—not even close.

So why not? What went wrong?

First, just like a human language is only useful because of the vast body of text written in it, a programming language is only as good as its ecosystem of existing packages and developer tools. Python’s ecosystem is so large and robust that it is nearly impossible to displace.

Second, Julia has never won major backing from Big Tech. In the past, when little-known niche languages rose to mainstream prominence, it was almost always thanks to corporate support: Apple adopted Objective-C for iOS development, Google backed Kotlin for Android development.

But third, and this is my core argument: nothing actually went wrong. Julia is a niche language, and it is extremely successful at what it was built to do. In all likelihood, Julia will persist, small but deeply loved by its users. It is already used for high-stakes, demanding work at institutions like ASML, CERN, and NASA, and for critical projects ranging from new drug discovery to cutting-edge advanced machine learning.

Even if Julia did eventually replace Python one day, I am not convinced it would fully solve the two-language problem—or that any single language ever can. While the problem is most often discussed in scientific computing, it exists in every area of software development. In game development, game engines are written in C++ but game logic is scripted in Lua. For server backends, developers rely on a wide range of easy-to-use languages like Python, Ruby, and JavaScript, but when maximum performance is required, the core work gets rewritten in Go or Rust. Conversely, ambitious attempts to use Go or Rust for frontend web development have almost entirely failed.

But that does not mean we will be stuck with this tradeoff forever. Perhaps one day a thinker as insightful as Iverson will find a way to bridge this gap once and for all. When that day comes, make sure you watch their Turing Award acceptance lecture.

This is the second installment in a three-part Machine Readable series on AI-enabling programming languages.