Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Faster Python with Guido van Rossum

softwareatscale.dev

Post reply on HN
Print view View original

81–90 of 251 posts

Re: Faster Python with Guido van Rossum

#81

Post by taeric »

orf wrote: post #73
taeric wrote: post #67

Earlier quoted context omitted.

I take that as "keep running pip install on yet another discovered dep until the script works." And heaven help you if you accidentally get conflicting versions installed in the same venv. (By conflicting, I mean two libraries that both depend on different versions of the same underlying library. Odds of this increase dramatically the more you use.)

Pip now checks this, but you usually use something like Poetry to give you a concrete lockfile with the correct transient dependencies locked in.

My "heaven help you" was more that, if you are in that situation, you don't really have an exit strategy in python. Do you?

Re: Faster Python with Guido van Rossum

#82

Post by ferdowsi »

ck_one wrote: post #63
stinos wrote: post #38

Earlier quoted context omitted.

I have become increasingly convinced Python as a language is a "trap" for any use of notable scale I assume you're saying this out of experience, so can you give a practical example of what you call 'notable scale'? And are you talking about desktop or web or mobile, or just all of them? Just so that we know what you are talking about in a concrete way. Not the 'large software with large number of developers is alway…

+1 Would be cool if some experienced dev could share some estimates when the Python scaling issues start. When you build a backend using Python + Django/FastAPI, I assume in most cases the DB and not Python is the limiting factor. Moreover, you could always spin up more workers to mitigate scaling issues. When you train ML models, your Python code just calls C++ functions. Python is not a limiting factor here either.

I worked for a startup that built their services using Python and Twisted. The codebase was a monolith broken up into several Twisted services, by the time I left it was probably 200k LOC of Python.

For us, the scaling problems started when we had two independent teams working in the same codebase. The extreme dynamism of the language meant that classes and data structures were being mutated willy-nilly in ridiculous ways across the execution flow. The lack of static typing made onboarding new developers difficult as they had to parse generations of excessively clever code and magic left behind by departed developers. This problem has only gotten worse in Python 3, which keeps piling on more ways to accomplish the same task.

The deployment story was also awful, but I don't think that's a surprise to anyone who has deployed Python at scale.

In terms of raw performance, at one point we estimated that our Python stack was adding 3-400ms of request latency compared to a comparable system written in Go. With the Python 3 deadline coming, we convinced management to invest in rewriting performance-critical parts of the service in Go, instead of the migration to Python 3. I left before the project was completed but we were already seeing massive improvements.

Re: Faster Python with Guido van Rossum

#83

Post by indymike »

colejohnson66 wrote: post #37
indymike wrote: post #35

Earlier quoted context omitted.

> This means performance will fall further and further behind compiled languages. This is exactly as it should be: the nature of the interpreter is that it has to do a lot of the work a compiler does when it compiles whenever a new command is run (and in Python's case, that is before you cover the whole "everything is an object" part). Yes, some of it can be mitigated, but the expectation that an interpreter keep pac…

> What I'd love is a language that can be compiled (and be highly optimized) and interpreted without changing it's behavior. The developer experience with an interpreter is fantastic, the performance of compiled code is... better. You mean something like a byte code like language with a JIT system? Like Java and C#? C# in particular now supports AOT compilation, but can still be run as “interpreted” CIL.

Having a VM / JIT in the middle is a way to get there, but ultimately, different. At least in Java's case, my code targets an abstraction instead of hardware, so I don't get the full benefit of compilation. Performance is part of the story... access to the OS and hardware is another.

Re: Faster Python with Guido van Rossum

#84

Post by joconde »

ctur wrote: post #4

I have become increasingly convinced Python as a language is a "trap" for any use of notable scale, be the scale about number of developers, codebase size, or performance requirements. It's a great 0->1 language and great at simple glue, but eventually you hit a wall and have to keep investing larger and larger amounts of people or computing resources to get continued returns... all due to fundamental design decision…

We started a project using typing annotations for everything, and it's really a pleasure to use. It's like the type safety of C++ without the insane language complexity; the "advanced" parts of the language usually make intuitive sense.

For our use case of deep learning, REST APIs, and image processing (often a mix of these), Python seems like the best choice we have. The GIL isn't a problem at all because all our computations are done with NumPy or PyTorch, which release the GIL during most of their operations.

Re: Faster Python with Guido van Rossum

#85

Post by musingsole »

gzer0 wrote: post #39

Python is a very easy language to learn and allows the user to build complex systems without having to worry about the syntax. However, this ease of use has led developers into using Python for various purposes that are not right for the language. Python has a fundamental design decision that is difficult, if not impossible, to fix - its dynamic typing. This means it allows users to run code without having to declare…

If you fed yourself, it was a perfectly apt use of the language. Purity is just navel gazing.

Re: Faster Python with Guido van Rossum

#86

Post by rowanseymour »

ctur wrote: post #4

I have become increasingly convinced Python as a language is a "trap" for any use of notable scale, be the scale about number of developers, codebase size, or performance requirements. It's a great 0->1 language and great at simple glue, but eventually you hit a wall and have to keep investing larger and larger amounts of people or computing resources to get continued returns... all due to fundamental design decision…

I feel pretty similarly. Our product used to be a Python/Django monolith and over the years we've ended up pulling so much of the functionality out into services written in golang. It was fantastic for getting the product up and running relatively quickly, and we're still very happy to let Django take care of the frontend and database migrations. But when your codebase has gotten big, refactoring in Python feels like Russian roulette, and when you're doing a lot of background processing, celery feels like the wrong tool for the job.

Re: Faster Python with Guido van Rossum

#87

Post by igouy »

pyentropy wrote: post #55
wil421 wrote: post #14

Earlier quoted context omitted.

Do you have the opposite experience? A language used by FAANG that doesn’t have performance issues at their scale. They seem to invest a lot in JavaScript which is not what I’d call a performant language and as you’ve said Python. I’ve used Python for more scripting type tasks and creating basic APIs to get specific jobs done. I’m very weary to go “all in” on Python for an app based on all the feedback about performa…

> They seem to invest a lot in JavaScript which is not what I’d call a performant language JavaScript (V8 at least) is extremely performant, near native code performance. Considering how dynamic it is, it's not an easy feat but Google, Apple and Mozilla work a lot on it. Here's a benchmark where JS is 50x faster than Python: https://github.com/kostya/benchmarks Note that PyPy does much better.

And some where JS is not 50x faster than Python: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Faster Python with Guido van Rossum

#88

Post by singularity2001 »

taeric wrote: post #67
aazaa wrote: post #54

Earlier quoted context omitted.

What are "hunter-gatherer-style installs?"

I take that as "keep running pip install on yet another discovered dep until the script works." And heaven help you if you accidentally get conflicting versions installed in the same venv. (By conflicting, I mean two libraries that both depend on different versions of the same underlying library. Odds of this increase dramatically the more you use.)

yeah people are often lazy about adding a requirements.txt

Re: Faster Python with Guido van Rossum

#89

Post by at_a_remove »

streamofdigits wrote: post #69

I wonder now that python made it to the big league, so to speak, if there shouldn't be more high level review of what exactly it should aim to be as an language and ecosystem going forward. Is the speed optimisation problem even well defined otherwise? E.g. tackling performant numerical computations via numpy and other such libraries seems to be a workable pattern. Even with compiled languages like C/C++ and fortran…

I agree, it needed everyone to step back and make choices as to direction.

Instead, we got the "stone soup" where everyone wanted their favorite feature from some other language added in. You'll see this in most languages, where people want something from another language they are more comfortable with. Privately, I refer to this as the California problem: people move away from California (or anywhere else really, I am picking on California) but then bring all of the baggage and voting habits that made California unpalatable to them eventually.

Python is especially vulnerable to this because it conflicts with "There should be one -– and preferably only one –- obvious way to do it." The more features added to the language, the more ways there are to do something, and we then must invent new idioms and lean on "convention."

Re: Faster Python with Guido van Rossum

#90

Post by overgard »

Ugh. Python could be fast, but the python core team / GvR put so many ridiculous constraints on what can change that maybe at best it gets like 10% faster, some day. Anything meaningful means breaking compatibility with extensions, and they absolutely won't do that. I feel like GvR got burned in the python 2->3 transition, but he learned the wrong lesson. The lesson he seemed to learn was never break compatibility but what he should have learned is don't break compatibility for stupid things nobody cares about. Making the interpreter much faster is something people would care about, but they'll never modify it in any meaningful way nor will they ever endorse something like PyPy.
Post reply on HN