Live data from Hacker News

Faster Python with Guido van Rossum

softwareatscale.dev

61–70 of 251 posts

Re: Faster Python with Guido van Rossum

#61
Python will always be important to me. It's the first programming language that I've learned, and it allows me to support my family. It's awesome that almost any problem I have, there is a library or wrapper ready made for me to use. I can google just about any error and get a solution right away.

But I've found that I really dislike maintaining larger Python codebases. Whenever I've tried to develop packages or libraries, or create executables it always felt really clunky. And when it comes to personal growth as a programmer, I find it's just too easy to stack ready made libraries on top of libraries, without ever coding things from scratch.

But I'm glad to hear that there has been more focus on improving CPython's performance. I don't disagree with the things that the Python Devs have chosen to focus on, and I don't think anyone can really say it hasn't been successful for them. I use Python for work, so I won't forget it anytime soon, but for programming at home, I'll use other languages that align more with my opinions of programming that I've developed after having used Python for an extended period of time.

Re: Faster Python with Guido van Rossum

#62
post #50
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 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.

Re: Faster Python with Guido van Rossum

#63
post #38
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 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.

Re: Faster Python with Guido van Rossum

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

Ok, let's admit it, writing bad Python code is very easy, as it is in every dinamically typed language, like Javascript... ... but I think you're forgetting the real motivations that drive people to use Python: it's easy to learn, it's very readable, there's a large (and not so much toxic) community behind, it's versatile. No one is saying that it will replace every other language, but it still can find its space eve…

I think the "dynamic" jab is a bit of a trap, itself. It is easy to write bad code in most any language. Anyone that tells you otherwise is trying to sell you something.

Re: Faster Python with Guido van Rossum

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

Ok, let's admit it, writing bad Python code is very easy, as it is in every dinamically typed language, like Javascript... ... but I think you're forgetting the real motivations that drive people to use Python: it's easy to learn, it's very readable, there's a large (and not so much toxic) community behind, it's versatile. No one is saying that it will replace every other language, but it still can find its space eve…

Readable varies by person. Myself, I find the decision on significant whitespace to make reading Python like reading English with no punctuation or capitalisation.

Re: Faster Python with Guido van Rossum

#66

Earlier quoted context omitted.

Also, typing in python has a "kluge" feel about it. It's like most things in python: it works nicely on toy examples, but is rather frail on the edges (if you're not convinced try to define the json type). I also think they chose the wrong strategy (type inference would have been way better) To use a metaphor: Python is the duplo of programming languages.

Python has always had strong, inferred typing. It’s just that you can rebind variables.

_static_ typing.

Re: Faster Python with Guido van Rossum

#67
post #54
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".

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

Re: Faster Python with Guido van Rossum

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

pypy in general works better, sometimes equal, sometime slower, and sometimes doesn't(library support is not 100%). the problem whit javascript is mainly no type check in compile time making lot more mistakes if you use a compile langues, that why a lot of big project now days use typescript, and force to use types

Re: Faster Python with Guido van Rossum

#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 these types of computations are best handled with tuned libraries.

For other uses, e.g., API's fastapi/starlette claims to be as fast as go / javascript. Not to say that there isnt a performance issue, but who exactly is experiencing it as a generic issue? E.g., I know for a fact that some python based desktop GUI applications have performance issues (...) but it could be the implementation and in any case GUI use is a bit of a niche (and python on mobile which is the dominant user device these days is very very niche).

Re: Faster Python with Guido van Rossum

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

Python is great for developing tools for infrastructure management, for scientific computation, and for small-medium web applications. Given its best in breed interoperability with C/C++, it is also good as a shell language for a top level project that incorporates other sub projects.
Post reply on HN