Considering the Python team's paradigm shift regarding the tradeoff between simplicity and speed, and the creation of the Faster CPython team (Thanks Microsoft !) that is getting everything upstream very quickly, I expect a massive evolution in Python's speed in the next few years.
The SBCL Lisp compiler (incidentally, the compiler is also called "python", which predates the PSF trademark ...) achieves much better results without millions of corporate dollars sunk into it.
Speeding up Python has been a lucrative business for more than 10 years, with dozens of projects and very little results.
I'd just use another language if speed is the issue.
And yet despite 30 years of people telling everyone how lisp is amazing, most people keep avoiding it despite that it's free, stable, and available everywhere. Meanwhile, new languages like rust or zig have no problem to be adopted, C#/Php/JS/python are still used massively and produced a lot of value.
But it's probably everybody that is wrong, there is no way Python has a value proposal that is worth something to a lot of people.
A lot of comments are suggesting to use better performing alternatives but they're ignoring the potential cost savings in hardware alone with small, incremental improvements. Performance might be fine but saving off 1-2% in hardware costs could be significant for a large scale app (like Instagram)
The thing is, it takes a huge scale for web apps before python becomes your bottleneck. Between caching, async, task queue, reverse proxes, databases and compiled extensions, you have so many performant options to glue with python that any hardware saving is more likely affected by your choice between redis, postgres and clickhouse than by the language you query them with.
Exactly. It's fine that the PSF and others are tackling performance seriously. But in addition to your point, in the 90% (made up on the spot) of the problems python is perfectly suited for, performance is simply not a consideration.
The one thing that keeps bugging me about Python (ignoring speed for a moment) is the lack of attention to seamless pain-free deployment.
There are two types: Web and desktop. Both are a mess.
On the web the "easy button" is to pay for a dedicated service that is setup to specifically deal with the fact that deploying a Python/Django app to a Linux server is a nightmare and a mess. You can deploy a PHP application to any server you care to choose from any hosting company in the world. Grab a cheap GoDaddy server and off you go. It's that simple. With Python? Forget it.
To some extent I blame this on the simplistic integrated development server trick. Sure, it's great, you install Django and you can see a site on your computer with no effort. And then comes the reality of moving whatever you created to the real world.
On the desktop, well, again, it's a mess. As much as people love to dump on Visual Basic, the one thing they got absolutely right was that you could develop an application, test it locally, and have it in installable form to use internally or send to customers with zero effort. Back in the day we created dozens of tools, both for internal and external applications both with VB and VC++ (these were Windows-based) and Objective-C for Mac. Python does not make this simple at all.
In my opinion, Python developers really need to take this aspect of how software is uses seriously. The only use for a language in isolation of creating tools people can use is in academia. Outside of that, we need to be able to deploy applications, be it web, desktop or mobile. Sometimes it seems zero thought or work has been given to this reality.
How crazy is it? Try to create just a simple desktop console application. Something silly, like a console-based calculator or hangman game. Now try to package it in installable form for delivery to Mac or Windows users who need to double-click on an icon and install/uninstall the application as they would with anything else on their systems.
Why can't Python do that when VB was doing it decades ago?
What boggles my mind is that Python has had billions of dollars of direct and indirect investment, with participation from every nook and cranny of the software syndicate—academia and industry—yet... this is all you get.
- it was born 30 years ago in a different time and carry the weight of those decisions and legacy
- it only got serious focus and investments the last decade, while alternative got 100 times more
- "this is all you get" downplay the enormous qualities of python to focus only on what's wrong with it. It never was in a situation to have success by default, it gained market share because it was good. No monopoly on the browser, no jump start at the begining of the web like php, no .net style founding by a giant. Somehow, the author must ignore some inherant good stuff to the language.
The same is happening at other major tech companies, e.g. Shopify.
They've very likely made their calculations, and assessed that paying engineers for speeding up the language, was overall preferrable to rewrite part of their (very large) systems and potentially extract them into separate services. It's unlikely that they just cargo culted.
Github/Gitlab, interestingly, did not take this road, and extracted slower part into Go services.
Stripe had the (IMO) most interesting idea - write a (Ruby AOT) compiler for the slow paths.
It'd be very interesting to see the precise/concrete considerations behind these choices, since generic considerations ("we love Ruby" :)) aren't very informative.
To me it looks like lock-in. They chose a language good for prototyping and quick iteration, and then their codebase gets stuck with a permanent performance problem.
You see the same problem in Python with regards to correctness - it's hard to refactor Python or change a large codebase and have it keep working correctly, so huge Python projects tends to ossify.
It may be a rational solution only in the short-term, but still an objectively bad solution overall.
The performance problems arrive very late, you can go very far with python.
So it makes sense to start with something that let you be as agile as you can, when you don't have money, and then, once you are filthy rich, spend the resource you have massively to solve your new problem.
Starting with something that is less productive to avoid a problem you might have later if you are rich doesn't seem practical to me.
> Starting with something that is less productive to avoid a problem you might have later if you are rich doesn't seem practical to me.
this is purely engineers' qualification issue, the fact that the hired engineers weren't productive in safer and more performant languages so they had to fallback to an inferior toolchain to seem like a productive team.
Simple tasks like fiddling with an API json response with rust, haskell or ocaml are always going to take longer than with python.
Now, doing it well will take as much time in any language.
But a huge amount of time is spent not doing things well:
- you try out ideas
- you explore data shape, results and systems behavior
- you demos things to get a sense of the solutions or sell something to management or clients
Eventually, you will have a very well defined problem with an optimal solution. But this is the last mile, unless you work for nasa.
E.G: currenly one of my client is a big financial structure, and they are creating a calculation engine. They have 3 experts on site, but they don't have the full understanding of the problem they want to solve, and disagree on the part they do understand. The result ? We have to rewrite a lot of code, and write even more code in an exploratory manner. This will likely go on for the next few years. You can wish for a better situations, or you can use a tool that make you productive in that situation.
> Simple tasks like fiddling with an API json response with rust, haskell or ocaml are always going to take longer than with python.
This isn't true, you are generalising your own perception of the tools you're not as familiar with as python. For instance, here's how simple json api fiddling looks in Haskell, if written quick-and-dirty prototyping way:
-- requires packages: aeson, wreq, lens
{-# LANGUAGE OverloadedStrings #-}
import Network.Wreq (get, responseBody)
import Data.Aeson.Lens (key)
import Control.Lens
main = do
result <- get "http://httpbin.org/get"
print (result ^. responseBody)
print "---"
print (result ^? responseBody . key "url")
Now, how exactly is it taking longer than with Python?
While I disagree with your "qualification issue", even that can be caused by money. Surely, hiring "more qualified" engineers cost more money that you may not have in a humble beginning.
As a counter example: I once had a short conversation with Reddit co-founder Alexis Ohanian about he and Steve dropping Common Lisp in favor of Python. They loved Common Lisp but I think the expression he used was something like "the Common Lisp code kept falling down" and said that moving to the Python ecosystem stabilized things.
I share this experience, as a Common Lisp developer (for 40 years!). I feel like while Common Lisp is a fantastic language for many reasons, I also understand that in many situations the Python ecosystem is a better choice.
That needs expanding though. A good Common Lisp compiler, e.g. SBCL, does perform a bunch of checks for correctness during compilation, which can further improved upon by adding static type declarations. The (C)Python interpreter o.t.o.h. does verify only the syntax in the most shallow way. Type hints there can be used by a linter (and perhaps by an alternative or future implementation of the Python interpreter), but I don't think such type hints were available at the time Reddit chose Python.
Python's significant indentation might make the source code more (human) readable (and that's really it's magic power), but poses a challenge during refactoring.
Without question you'll find more easily competent Python programmers than Common Lisp programmers, but that Common Lisp would lead to more fragile code isn't as obvious.
> it's hard to refactor Python or change a large codebase and have it keep working correctly, so huge Python projects tends to ossify.
Although I don't work in Python, in general, projects written in dynamic languages can be refactored if they've been developed in a disciplined fashion, that is, with substantial test coverage (I guess that in modern projects, with type checking, the need is significantly reduced). This is not unrealistic (I'm currently worked on a large-but-not-huge project, and it's perfectly possible to refactor), although of course, whether dynamic language with lots of testing is still more efficient (in terms of engineering resources) than static language with less testing, it's another story.
I was working on a code base where testing was inconvenient (re-striping a large RAID array took hours) and I can think of scenarios where testing is impossible (or at least very costly). Test driven development isn't always the right approach.
Having substantial test coverage is a different concept from TDD (which is an approach to software development).
It's not clear how restriping an array is related to a test suite, also because if an API is slow to test (e.g. restriping), it's slow with either static or dynamic languages.
In general, if a certain API is impossible to automatedly test (this is a common case in both static and dynamic languages, for example, for web services), one stubs the API; with dynamic languages one will be certain that the tested codepaths until the API are correct. With this strategy, the difference with a static language is minimized (or not existing at all).
It makes sense to me. Nowadays, all the GAFAM has solved most problems python is good at: glueing a lot of things, experimenting with ideas, bootstrapping new product, hiring and training a lot of new people fast.
They now are in the optimization phase. They first picked the low hanging fruits, but after 10 years of doing that they need to fine tune. For them, gaining 20% of speed can add up to millions of dollar a day, so it's now the new priority.
Just like with JS in the 2000', today they have to decide if it's worth rewritting python code or just improve the platform. For some projects, they made the calculations and it was just cheaper to improve the plateform. We got V8. Now Python is getting the new focus.
When we created our own version of AOLServer, also with Tcl, I quickly learned that interpreted language + continuously rewriting code into C, wasn't the way for doing distributed systems where performance matters.
Indeed this experience eventually made us jump into .NET as we had early access to it as Microsoft partners, and a couple of years later some of the people on this team went off and founded OutSystems.
20 years later, apparently this lesson of using scripting languages without dynamic compilers seems to have to be relearnt the hard way.
It's not that bizarre. It's path dependence. They have an existing codebase with hundreds (thousands? tens of thousands?) of person-years of effort contributed in python already, so a complete rewrite would be too expensive to consider.
The question is why they chose Python for apparently performance sensitive problems in the first place. The fact that they're now bumping against a performance wall and can't get around it by rewriting is a huge drawback when choosing Python as the language in the first place.
Awareness that organisations often end up in these problems should be considered when choosing the language for a green field project.
The decision likely got made before performance was a major constraint.
As I understand it, Instagram is a python codebase and (guessing) may be the primary motivator here.
Probably the first, say, 100 person-years of effort poured into the Instagram codebase were done at a time when product development velocity, not performance, was the main priority.
Instagram wasn't performance sensitive at all. It was iteration sensitive: if the team hadn't done it, some other group of people would have sold a company for billions of dollars to Facebook.
Part of the reason is CPython left performance gains on the table for so long, in favour of implementation simplicity. It wasn't that difficult to improve on its performance. That policy seems to have changed now, though.
Well, in 2008 the PSF had a budget of $500k for the entire world. To compare with JS, this is the order of magnitude of the salary of one single person working on google chrome.
The community didn't have a lot of resources for a long time, and so had to prioritize: it chose to focus on python strenghts, and not compensate for weaknesses. It couldn't do both. Keeping the implementation simple was also a way to keep the project manageable on the cheap (and by cheap in mean in work hours, since the first 15 years, most core devs were just doing it for free).
Today, a lot of companies with a lot of money have much to gain to invest in python, and so we can finally have our cake and eat it too.
Why? The language is great, it's the runtime that needs some work. We have bun because someone thought kind of the same thing about Javascript and decided to improve the runtime rather than to learn Rust.
I'd be interested in hearing from others, but I wonder what differences there are for optimizing JS vs Python. A few things come to mind:
1. Python has a ton of C code in its libraries/stdlib, JS did not have that for the vast majority of its usage (browser). Optimizing across the FFI boundary seems unlikely to be a reasonable goal and may complicate optimization opportunity. Let's say you want to do some sort of optimization pass to make sure that `str.append` is not getting overridden - how are you going to handle native code?
2. Python is obscenely dynamic. Runtime generation of classes is not uncommon at all - for example, `@dataclass(slots=True)` creates an entirely new class.
You can overwrite methods, functions, there's heavy use of globals in libraries, no such thing as private implementations, hooks into everything, even importing code has side effects so you can't reorder or lazily import automatically, even reordering imports is unsafe in Python.
It seems really hard to optimize Python at all, and I wonder if we could ever reasonably expect to see a "V8-like" runtime, even assuming that there's funding, which I also doubt. Unless you're willing to break the language I just don't see a Python runtime overcoming these issues. Or introduce something like 'strict' where these things aren't possible.
Dynamic languages aren't just about the syntax, they are also about copious amounts of implicit casts and slow but flexible data structures to make working with them possible.
Python has a very good set of data structures and implicit casts, that is the main reason it is popular. Compare to jagascript for example... Anyway, making python fast while keeping all those casts and data structures is very hard, Javascripts casts and data structures are bad for the programmer but very good for the interpreter so is much easier to optimize which is why it runs orders of magnitude faster.
As someone who uses python in their day job, "IO bound" is a lie that is perpetuated to cover for the failing of the language. IO is very fast these days and python has the capacity of choking the cpu even on genuinely io bound problems .
For example, do you think that python is an appropriate language to write pylint?
* It uses an interpreter, which is slower than compiled code
* All objects carry a dict to contain arbitrary attributes - this creates huge overhead
* Even when the dict is suppressed with __slots__, all containers (all classes, even!) are untyped, so extracting any field causes dynamic dispatch
* Objects cannot be stored inline in containers
* Integers are variable-sized, and thus slower.
Of course, you might counter that one could simply make a version of Python which is compiled, where all classes have a well-defined typed layout, where some classes can be immutable for performance, containers are typed, integers are machine integers, etc. But then I'd argue you're talking about a completely different language (Julia fits this description perfectly)
All my points above are about the language semantics of Python, not the implementation. Some of them may be optimized some of the time with a clever enough JIT - but only a few of these points. That's why PyPy is not as fast as C.
PyPy very much can handle all of the above cases! You should check out some of their recent papers about unboxing fields in objects. Some things are language semantics (__dict__, etc) but are often faked by proxy objects since most people don't actually care about the dict.
And despite all of this, Python has generated billions (trillions?) of value, and continues to do so.
Perhaps it's you who is focussed on the wrong things? Maybe some of these issues can be improved over time? Maybe none of those things actually matter in the real world, outside of niche use cases?
Are you arguing about whether Python is a good language or whether it's a slow language? The former is a matter of taste, the latter is objectively true. And there are good reasons to believe it will remain true.
It's created billions of dollars in value, sure. So had JavaScript and PHP. Doesn't mean they're good languages. Mediocrity gets you far, if you're at the right place at the right time.
I disagree as well. I was working at YouTube during the rewrite from python to c++ and a lot of people at Google looked at the problem to avoid a full rewrite of a major product. We still ended up doing it regardless of the pain of using Swig to wrap C++ code. Not missing that at all.
To have different implementations we first need a "Python language specification" which doesn't exist. All other implementations have to be compatible with CPython to increase their chance of getting wider adoptions.
Good enough in what way, specifically? Python is exceptionally popular not because of speed, but because of its wide compatibility, extensive list of maintained libraries, good learning paths, and most likely because its fast enough for most things.
Every iteration of Python for some time now has added a not insignificant speed boost. It's not as fast as C, and nor will it be given how it works, but it certainly is fast enough for a great many situations and tasks.
All of the above doesn't make it the right tool for every job. Sometimes you need to hit a nail, and you don't have a hammer but you do have a lump of hardwood. And in that situation, you make an assessment if in the long term you need to hit more nails regularly so you invest in a hammer, or just occasionally and you're ok with the lump of wood. It's subjective.
The speed of the programming language, in many applications, is a lot less relevant than the overall architecture. For example if you’re running a Web server and you’re serving a request through some hyper optimized C program, that is “fast”. But using a CDN in front of a slow Python server is almost always going to be faster for end users. Point is, the application is often just one part of a system. Python might let you develop quickly and avoid footguns, and having one slow link in the system doesn’t mean the system as a whole is gonna suck
I've no love lost for Python, but in regards to what Python's creator may have said at the beginning, I'm reminded of the Linux announcement -- "just a hobby, won't be big and professional" and "NOT portable", "probably never will support anything other than AT-harddisks."
Julia sounds wonderful on paper, but as soon as I want to work with the sorts of data that is my bread and butter, the ecosystem in Julia is empty, whilst Python is fully featured.
Spoken with the arrogance of a true software engineer.
It's common in science to see computer scientists implement domain-specific software with a hopelessly naive understanding of the domain, leading to biased, wrong, or misinterpreted results. Like, go to any bioinformatics conference and you will find these people.
"What do you mean I can't just use a database of clinical pathogens to make a tool that generalises to all bacteria?"
Mh, I read the parent's post as: "You can count on science producing things that software engineers will complain about (and therefore use). But it's rare for science to use stuff produced by software engineers at all, and hence there's no complaint that way"
It is also common in science to solve problems by producing unmaintainable write-only code and managing dependencies by bundling up the entire universe into one enormous distribution.
This approach works for science, not for software engineering in general. Hence, we do not adopt it.
The problem of a lack of understanding of the domain exists in all domains, but many scientists are particularly inept at expressing their precious ideas in terms that an ordinary person could hope to comprehend.
> It's common in science to see computer scientists implement domain-specific software with a hopelessly naive understanding of the domain, leading to biased, wrong, or misinterpreted results.
I still believe that the main reason Python is slow is because people kept repeating that Python is slow and just accepted this as unavoidable. Combined with how nobody sponsored the main work on something like this, even though everyone would have benefited, and sparked all these independent projects.
Given what insane performance has been extracted from Javascript, I'd expect the limits for Python being within an order of magnitude from C++/Rust.
