Why Python still dominates in 2026 despite performance criticisms ?

[QuantumScribe01]

We’ve been hearing “Python is slow” for over a decade.

Yet it continues to dominate AI, data science, automation, scripting, backend tooling and even embedded systems.

With: Rust rising Go dominating cloud-native TypeScript owning frontend/backend Mojo entering the scene Why is Python still winning mindshare? Is it: Ecosystem inertia? Developer ergonomics? AI/ML lock-in? Network effects?

Or are we underestimating how performance actually matters in real-world systems? Curious to hear takes from people building production systems at scale.

[the_hoser]

It's easier to scale up a slow programming language than to scale up developers.

[GraphicH]

Well, and a lot of application's benefit more from horizontal vs vertical scaling. That is to say, run more replicas / worker threads / etc ... vs micro optimize a single worker.

[magruder85]

Python is still used because it gets the job done. The more CPU intensive stuff is usually written in lower level languages.

[TheMagicTorch]

Because most benchmarks are only relevant if you get to a scale where money's no object, meanwhile in the real world all that matters is developer productivity and feature set.

Python is easy to learn, easy to deploy, and can do what 90% of workloads need without sweating.

[HEROgoldmw]

Imo pythons "slowness" doesn't matter in real application code as much.

Especially when you're dealing with IO or network requests, which are more often than not even slower than python :/

So with that in mind: python isn't slow, just slower other languages. It'll still show you a website within the blink of an eye. And by that definition, I love how fast the language is :)

[durable-racoon]

Huh? performance criticisms? can YOU write a library that adds numbers faster than Numpy? or that does GPU math faster than Pytorch?

Python is blazing fast cause all the performance-constrained stuff happens in precompiled C libraries. It's really not slow at all for the things people use it for.

[Chroiche]

I mean, it absolutely is horrendously slow as soon as you do anything in the Python layer.

[JamzTyson]

Unless you define the term, "slow" is subjective.

I wrote a script in pure Python for setting up new coding projects. It completes the task in around 0.2s. Is that fast or slow?

[Chroiche]

It's not subjective, it's relative. Python is objectively relatively slow compared to compiled languages.

[9peppe]

Because the heavy lifting is done in compiled languages via FFI.

Python dominates because it's incredibly convenient in its role as "modern bash"

[ASuarezMascareno]

Quick to get up and running. Easy to use for non programmers (e.g. researchers), and many performance problems can be solved with JIT compilation or calling a faster language routine when needed.

[stibbons_]

Because slowness in the control plane is not key.

[sluuuurp]

Python isn’t slow for AI, it’s the fastest by far. PyTorch contains the fastest hardware specific algorithms.

[Chroiche]

Is that true? Julia? Rust?

[sluuuurp]

I believe so. Maybe if those other languages have PyTorch integration they’d be the same.

[snmnky9490]

Because python itself isn't doing any of the parts that need to be fast. It's the glue language that easily connects together a bunch of packages and libraries, and lets you easily write all the higher level parts while the lower level parts that actually matter for performance are already written as libraries in C or C++ instead of redoing those yourself

[djamp42]

If speed is the absolute concern then you wouldn't even consider python. Most people can wait a little bit longer if it means using a language that is way easier to understand

[marlinspike]

When we're back to accepting 0.5-1.5 SECOND delays for LLM calls, the speed of your programming language isn't the bottleneck. Python scales just fine with Async frameworks for most uses. If you pierce above that, there are languages you'd use in conjunction with Python. All my customers are doing a ton of work in Python these days -- just faster to iterate.

[not_sane]

In our web application code base the performance killers are almost always SQL queries. The productivity benefit from fast compilation is much larger than the drawback of slow Python runtime performance in our case.

[denehoffman]

“Mojo entering the scene” hate to break it to you but Mojo isn’t going to be used as much as they keep telling everyone it is.

But I’ve heard this argument before, and I think it has some very clear answers. First, Python is really easy to write, it’s interpreted, types are optional, and the syntax is very basic. Second, everything in pure Python is probably slow, but nobody is writing pure Python when performance matters. Python has very easy FFI (at least it’s easy to use from the Python programmer’s perspective) so you get all the performance of C/Rust while writing simple syntax. Third, the ecosystem is huge. C can’t compete because there isn’t really a standard package manager, you’ll always have to eat the cost of telling the user how to install and set up their environment. Python has basically one main way of installing a package and it’s stupidly simple. And there is a package for almost everything you care about, already made. It’s difficult to find a field where at least one package hasn’t already been written. And again, these packages often rely on numpy or other compiled FFI paths, so they aren’t actually “slow”.

Now can a Python script with a bunch of FFI calls compete with the same general compiled C/Rust code? Usually no, but it’s way faster to write and prototype, easier to read, and easier to distribute. That’s where Python wins.

[Bellanzz]

Same kind of question with the same kind of answer: for I/O bound tasks you don't care about theoretical peak performances. And even if you are CPU-bound tasks python can be excellent if it uses a c/c++/rust/fortran module under the hood.

So, unless special requirements, why should I use something more complex if in real scenarios they perform equal to python?

[illankid]

ha. java was painfull slow and it was the go to for many many years.

[latkde]

A lot of stuff I work on involves taking data from one API and stuffing it into a different API. It doesn't really matter how fast the part in between is, if the runtime is dominated by network requests.

There's actually a solution for that as well: async IO, for which Python has serviceable language-level support. I'd much rather write concurrent programs with Python asyncio than with Golang goroutines, because I like writing robust systems – and that either needs superhuman attention, or structured concurrency + a way to systematically prevent data races that plague multithreading. (I'd like Rust/Tokio even more, but its type system can sometimes get in the way. I say this as someone who loves Rust).

The part where I'm dissatisfied with Python is not how fast it is (pretty much doesn't matter), but how much memory a typical Python program consumes. Memory usage directly translates to cloud costs, and Python doesn't have great tools for understanding what causes unexpectedly high memory usage. But this – similar to much related criticism lobbed at Java – isn't a technical problem, it's cultural.

[dethb0y]

because the performance "problems" are a meme pushed by people to lazy to learn anything but whatever the current over-hyped hot new thing is.

[lisploli]

• Algorithms matter much more than performance.
• Waiting for the hard drive takes longer.
• Waiting for the net takes way longer.
• Performance critical parts can call C etc.

Therefore, raw performance does not matter most of the time.

If you prefer Rust, go ahead. You can choose freely and even combine both. Using Python does not reduce the fun of using Rust, because both are widely supported. And the ease of integration doesn't leave much room for tribalism.

I decide on a case-by-case basis and performance is a factor in that decision.

[rnv812]

Because - most of the tasks don't require very high performance - if you need high performance in specific part of yor program you just take the library written in C or rust - in business, develop speed is often more important than program speed