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

101–110 of 251 posts

Re: Faster Python with Guido van Rossum

#101

Post by mynameisash »

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…

> eventually you hit a wall and have to keep investing larger and larger amounts of people or computing resources to get continued returns.

That's certainly my impression. I'm not a professional Python programmer, though I have used it in a few projects that went to prod. I really want to like Python, and it is really nice for some quick one-offs. However, in my project, where the codebase was 30-40% Python, I estimate that 80-90% of bugs and time spent were in Python. The other side of things was more or less write once, never revisit.

Re: Faster Python with Guido van Rossum

#102

Post by _wldu »

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 is my experience as well (but not at a FAANG). You can do things quickly in Python and it is a joy to write, but down the road (as you grow), you will regret it and find yourself re-writing it.

Re: Faster Python with Guido van Rossum

#103

Post by Joker_vD »

overgard wrote: post #90

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

The interpreter that breaks the backward compatibility makes that code run infinitely slower (i.e. it does not run at all) instead of running faster.

And it doesn't matter if the compatibility was broken for some thing you actually care about: if your code can't run at all until the broken third-party dependency is fixed by its maintainer, you simply won't upgrade, will you?

Re: Faster Python with Guido van Rossum

#104

Post by Mikeb85 »

igouy wrote: post #87
pyentropy wrote: post #55

Earlier quoted context omitted.

> 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/...

Did you look at the source of the programs where Python was competitive?

Python basically using C types and GMP to write C in Python...

Re: Faster Python with Guido van Rossum

#105

Post by coldtea »

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…

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

If you're a millionaire by that time, or have a strong established business, then it doesn't matter, it's a nice problem to have. Have your engineers have a go at it.

See: Dropbox, Disqus, AirBnB, and others...

And if you're not, then going from 0->100 in 2 years instead of 0->1 in a few months with Python wasn't worth it anyway (and you also don't have enough customers/users to make use of those 100x improvement).

Re: Faster Python with Guido van Rossum

#106

Post by madelyn »

wickoff wrote: post #96
nickjj wrote: post #72

Earlier quoted context omitted.

Sure, Rust too for some of the desktop app components. But the takeaway is you only need to do that when you're operating at mega scale and actually hit these bottlenecks. In a ton of cases you'll be completely fine serving a few million monthly page views of your SAAS app on a single $20-40 a month server using Flask, Django or whatever Python web framework you prefer. Performance will be really good too. Just talki…

You may be better off using rails instead to fully capitalize on rapid development through automagic.

I mean, yes, if you know Ruby. If you as a founder know Python, just use Django. They're sister frameworks.

Re: Faster Python with Guido van Rossum

#107

Post by coldtea »

ferdowsi wrote: post #62
nickjj wrote: post #50

Earlier quoted context omitted.

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

My understanding is that Dropbox has been building performance-critical parts of their services in Go since 2014 at the least. https://twitter.com/jamwt/status/629727590782099456 Like many companies, they had initial scaling successes with Python,hit performance bottlenecks and looked for a way out with faster languages.

So? If they started with those faster languages they'd have slowed down their rolling of features initially. They might not even be here now.

Re: Faster Python with Guido van Rossum

#109

Post by penteract »

stinos wrote: post #42

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

It seems possible that intel/AMD have used the Python interpreter in some of their benchmarks, with the result that they either add or tune hardware optimizations in ways that help it.

This could mean that people working on the Python interpreter encounter more problems with CPU magic than most people do, since changes they make move it away from what the manufacturers optimized for.

Re: Faster Python with Guido van Rossum

#110

Post by m4rtink »

bborud wrote: post #33

I'm militantly disinterested in the performance of Python until the deployment style of most Python projects is no longer "hunter-gatherer-style installs".

Is it really a problem of Python itself rather than project developers being too lazy to do proper package management?
Post reply on HN