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

41–50 of 251 posts

Re: Faster Python with Guido van Rossum

#41

Post by bcrosby95 »

ctur wrote: post #16
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…

Everything has performance issues but Python is at least one, if not two, orders of magnitude off of compiled languages like C++, Rust, and Go (despite Go having a garbage collector). They have various usability tradeoffs but once you get things working, at least you're not spending 10x as many cycles to do the same work as another language would need. (Java probably is also fine; I've less personal experience there…

Statically typed, garbage collected languages are all roughly in the same ballpark, on average (Go, C#, Java).

Re: Faster Python with Guido van Rossum

#42

Post by stinos »

Best quote at the end:

I wish I knew what went on in modern CPUs when it comes to branch prediction and inline caching because that is absolute magic.

Seems spot on, and I really wonder as well. Always had the feeling that some decades ago it was still possible to outsmart the CPU (well, and the compiler/optimizer) and get performance improvements by thinking like a CPU, but these days this seems to have become impossible, for this reason I guess?

Re: Faster Python with Guido van Rossum

#43

Post by cglace »

ctur wrote: post #22
nicolaslem wrote: post #7

Earlier quoted context omitted.

Isn't it that maintaining large codebases in the long run is just hard? What language is not a trap?

Fair, maybe it's always a matter of picking the trap you want :) If you are optimizing for 0->1, Python is great. But if you want code to live and evolve over time with multiple authors, or ever will care about runtime performance, it's a dead end almost from the first line. But sometimes the productivity benefit is all that matters and you accept you may have to throw it all out later (or invest insanely in making i…

As with any language it's how you end up architecting your codebase. I do believe python lacks an authoritative resource for what is "good architecture" which leads to a lot of the code scaling problems.

Re: Faster Python with Guido van Rossum

#44

Post by amelius »

jerf wrote: post #32
Qem wrote: post #6

Earlier quoted context omitted.

Given Python has the multiprocessing module, I always get confused when people talk about Python lack of support for multicore. What are the shortcomings of the multiprocessing module, that cause people to disregard it?

As a sibling mentions, the multiprocessing support is basically support for spawning new processes. It's better than nothing, but it's not very good for the performance. The real problem with Python multicore is that the main problem is solves is the one ctur is talking about, namely, "Oh crap, I used Python and it doesn't run fast enough for my needs... maybe I can run more processes?" Using a language that is alrea…

> Python is now only incrementally better than modern static languages in some dimensions

The main benefit of Python now over those newer languages is its ecosystem.

Re: Faster Python with Guido van Rossum

#46

Post by giovannibonetti »

indymike wrote: post #35
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…

> 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…

> The developer experience with an interpreter is fantastic,

By the way, there are some (high-level) compiled languages with REPLs like Lisp, Haskell and Elixir.

Re: Faster Python with Guido van Rossum

#47

Post by azeirah »

qsort wrote: post #27
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…

Pretty much everything you're saying matches my experience, so, playing the devil's advocate: - The typing argument is impossible to argue against, but isn't it the same problem you'd have with any other dynamic language? How is, say, Javascript any better? I don't see this as something that's specifically Python's fault, rather, yet another argument as to why starting a large project in 2021 without seriously consid…

For your first point, I don't think a language such as JavaScript -is- much better, which is why Typescript was invented as an alternative for larger codebases/organizations

Re: Faster Python with Guido van Rossum

#48

Post by amelius »

dom96 wrote: post #40
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…

If anybody is looking for an alternative to Python that is also a great 0->1 language but doesn't have the same wall as Python described here, check out Nim[1]. 1 - https://nim-lang.org

People's main reason for using Python is the ecosystem.

Re: Faster Python with Guido van Rossum

#49

Post by spamizbad »

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…

Most problems do not need scale. Some problems require it. For those: use one of many proven "fast" languages. For everything else Python (or similar language) is more than adequate.

Re: Faster Python with Guido van Rossum

#50

Post by nickjj »

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 have become increasingly convinced Python as a language is a "trap" for any use of notable scal

At what point do you embrace the trap and happily live with it?

For example Dropbox runs many millions of lines of Python, has massive traffic and their server costs aren't completely out of line for the service they offer. Their code base is also over 10 years old.

It seems to be working very well for them.

I talked to one of their engineers a few months ago. He gave me a complete run down of how they build and deploy Dropbox at https://runninginproduction.com/podcast/82-dropbox-gives-you....

Post reply on HN