Enterprises Hope That Python Will Make Them AI-First

I got the T-shirt, the notebook and the branded pin with the lock and the key. But why does Jane Street have a stand at a Python conference?

I spoke at Pycon earlier this month. Behind the massive stands from Meta (“we’re open source!”), AWS (“we’re open source!”) and Microsoft (“we’re really trying!”), tucked away in a corner, sat the Jane Street stand.

I’ve talked about Jane Street before. It’s a proprietary trading firm, known in the tech industry not just because they’re highly profitable, but because, and I quote Wikipedia, “almost all of its software is written in the OCaml programming language”.

That is, until now apparently.

Because the T-shirt that I’ve got featured two animals on a sidecar motorcycle, with the camel (representing OCaml) in the passenger’s seat, and the snake (representing Python) in the rider’s.

Decades after Yaron Minsky persuaded the company not to choose C++, Python is used in production at one of the most technologically savvy hedge funds in the world.

Here’s the thing: it’s not just Jane Street.

Revolut is expanding its team of Python coders, AstraZeneca switched to Python in order to develop its drug discovery software, and Stripe, when faced with the choice of keeping Ruby or switching to Java, ended up building a static type checker called Sorbet so that they could stick with Ruby.

At Kiwi.com, the company I work for, we use Python for everything. I wouldn’t be surprised if the water cooler runs on Python too.

Nobody is noticing this trend.

Because everyone, of course, is talking about AI.

I don’t know about you, but I’m already exhausted from following the news on AI. Yes, a report from Productiv puts chatGPT among the top 10 shadow IT apps. It’s used everywhere. I get it.

In contrast, what I want to talk about today is that these tools are embedded in a larger trend, one that has been running for a long time now. And that’s the slow drift away from Java and C# as the programming language choices for enterprise software, in favor of Python, Ruby, Go or Javascript.

Just like everyone a few years ago was using Oracle, and now no one does.

We’re still debating whether using AI to make engineers write code faster is a good thing.

Is losing the ability to build without an AI assistant a bad thing? Is the system built with AI as buggy as one built without it? Are we all going to be jobless?

I don’t care. Not because the questions aren’t worth asking, but because nobody really knows the answers.

But if we don’t understand the trends that made AI tools possible, we’re going to misuse them, because we won’t understand where they are the most impactful, and where they’re just another shiny toy.

Just like developers who aimlessly ‘vibe code’ themselves into a corner, executives and senior engineers who blindly declare themselves “AI-first” will disappoint those around them when their AI initiatives fail to deliver the results they proclaimed.

This is The Payments Engineer Playbook. Today we’re talking about what programming language to choose for your money software, from the point of view of the broader enterprise industry. I gave a talk on this very topic a while ago at Europython, and so if you’re curious to learn more about it, go watch it.

Otherwise, let’s dive in.

I have a confession to make: I build enterprise software.

By that, I mean the kind of software that Martin Fowler described in Patterns of Enterprise Application Architecture: systems that

• Handle a lot of persistent data

• Have a lot of concurrent users

• Provide a lot of integrations with third party interfaces

But although I’ve been building enterprise software for my entire career, I have never used any of the usual programming language choices, like Java or C#.

Instead, I build enterprise software in Python.

Some engineers argue that Python is not a language for “serious” software engineering. They believe that it’s a great language if you’re learning, or if you use software beyond engineering, like data science or DevOps. Serious engineers, they say, use serious programming languages.

Don’t get me wrong, Java used to be a better choice than Python not that long ago. It’s backed by Oracle, which means that their maturity, stability and performance is backed by a company with a track record. Running licensed software is a means of future-proofing your hardware (recall Java’s slogan: “Write Once, Run Anywhere”), and establishing clear lines of blame in case of defects.

That’s why banks, the quintessential enterprise companies, have traditionally relied on Java and C# for building their software.

But not anymore.

Some banks have taken a different path. In the UK, Monzo is building most of its tech infrastructure in Go, and in Brazil, Nubank has embraced Clojure.

And this is happening beyond the financial sector. Dropbox, for example, is a company that sells file hosting products, another good example of enterprise software. It builds enterprise applications, but it does so in Python.

Did Dropbox’s founders choose Python because it was trendy? Perhaps. But if trendiness were all that mattered, then nowadays Rust would be prevalent, having been the most admired language for years.

What does matter is that, had Python been a bad choice for Dropbox, the company would have never gone public at an $8 billion valuation.

Traditional enterprise programming languages are in decline. And there have been a few trends that are directly responsible for it. These are the trends that made enterprise software built in Python possible.

What are these trends? I’ve identified at least four:

• Hardware is both very fast and very cheap. After decades of innovation, cloud platforms like AWS can offer instances with dozens of terabytes of memory, 900 vCPUs and 200 Gbps of network bandwidth. Faster hardware makes efficiency not as relevant as it used to be.

• Service-oriented architecture (SOA). Enterprise applications can trade some of the efficiency gained with hardware for higher availability, faster development and more specialized teams using SOA or microservice architectures.

• Open-source software. Distributed systems wouldn’t have been possible on licensed software. Open source can now be as reputable as licensed software because associated business models have matured, either as a managed service provided by companies like Red Hat, or as an open initiative, like Python.

• Our Tech Society. None of the above would matter if all enterprise software had already been built. But our ways of doing business have become dominated by software, and nascent startups find themselves with billions of people as potential customers, competing against traditional companies using traditional programming languages.

All the obstacles to building successful enterprise software have crumbled down, except one: the customers’ costs associated with switching to a new solution. Speed of development is the dominant factor of enterprise software success.

It’s no longer true that the big eats the small. It’s the fast that eats the slow.

This explains why software is now delivered as a service, from a server rather than as a self-contained product sold in CDs.

It also explains

• why Agile methodologies are prevalent at big companies

• why enterprise software is now marketed to engineers (when it used to be marketed to executives)

• why not just Dropbox, but also Udemy, Sentry and others, have successfully built enterprise products using Python.

The key cost isn’t the actual development of software and its operation, but the client’s opportunity cost of choosing to integrate with an enterprise software product that fails to catch up with the competition.

It’s not seriousness or reputation that wins the deal. It’s the ability to keep up.

Java has nothing to offer to the product engineer with a greenfield project on their hands.

Sure, there’s a lot of Java still humming along, and that’s probably not going anywhere.

Perhaps the peak of Java coincided with the era where the software industry exploded, and we’ve tested all manner of ideas in the language, until it’s become an unbearable mess.

Many other languages have incorporated those lessons, without the unnecessary cruft.

This is more important than you think. As we incorporate more AI tools into the process of building software, tools that have been trained with code written in the past, a language that made so many turns and twists will lead developers to make turns and twists as a result.

There’s a critical tradeoff now in the choice of a programming language. Obscurity may lead to hallucinated code; but a badly designed language may lead to suboptimal vibe coding sessions.

You know, producing software that will make you slower down the road.

And, sure, potential customers aren’t going to risk integrating with your enterprise product if the first iteration isn’t of enough quality. But there’s an upper bound limit on how long you’re afforded to make the product better: how long it takes for your competitors to do the same.

If you’re trying to make your company “AI-first”, the language choice could be as critical as the AI tool.

After all, language is the middle L in LLM.

This has been The Payments Engineer Playbook. If you’re interested in diving into this topic a little more, check the talk I gave on this topic at Europython last year on the video below.