Python programming: We want to make the language twice as fast, says its creator

Also, the Python's C extension story is much better than most other popular languages, so that's something to think about as well if you seriously need performance in your app.

[0]https://marketplace.visualstudio.com/items?itemName=ms-pytho...

You don't need type hints for that, any old Python linter would have spotted this error...

I wrote a simulation of sorts in python a few months ago, and a scenario runner to crank through as many simulations in parallel as possible. I didn't have any particular goal for runtime, but the faster the better. I spent a day replacing an iterative solver with a closed form solution, and that made it about 10x faster alone. I spent another 20 minutes turning classes into slots and got an easy 50% boost on top of that. I run that code for a couple minutes every few days on my 8 core laptop from 2020. On my 5 year old laptop with half the cores, the same task is more like 5 minutes. Doubling the speed of that code would be really nifty, in that it would make the 5 year old laptop take a couple minutes, and the modern laptop take less than a minute. I'd probably double the number of scenarios and get a more statistically significant result for what I'm simulating.

I also like to use Cura for 3D printer slicing. That's pretty much all written in python, and while it's gotten faster over time it's still pretty darn slow. If that doubled in speed, it would be an awesome upgrade.

Yeah, who would appreciate a doubling of speed, e.g. needing half the servers or serving non-cached responses faster, or their scripts finishing in half the time, and so on...

I mean, if there was tradeoff for the end-user sure, but as it is, I can't even understand the reasoning behind this comment.

>If you want speed, you need complete control, mainly over memory.

That I might be OK without the ultimate in speed (that I'd have with the above in C or Rust, etc.) does not mean I would not absolutely appreciate more speed in the things I use Python for now, especially if it came for "free" (e.g. not with Cython or having to wrap C extensions, etc.).

Would you be saying the same ("doesn't matter") if Python was instead made 2 times slower?

Python is something like 40 times slower than C, lisp gets much closer with something like 4 times slower (all of this heavily depends on what you are doing obviously, so just rough ballparks here).

It's actually quite possible, and depends on the scenario.

A dynamically-typed language can analyse actual runtime type use and specialize function calls with a JIT, for example. It's also possible (and there's work in this area) to keep the specializations around for quick startup in the next runs... (and of course, drop them if they no longer hold).

That's how Javascript is much closer to native than Python - in some cases just 2-3 times slower than C. Lisp did very well too (better than more than a few static languages).

And that's with the extreme meta-programming / reflective behavior (which both Python and Javascript have). With less such, one could make a dynamic typing language that can be trivially JITed to run very close to native.

This is the problem that above initiative wants to fix.

If you're aware of the issues and have other options, you wouldn't look to Python for performance unless it was a case where Python is just used to script pre-existing C libraries (ex: machine learning). For general performance, you would choose Go over Python. If you choose Python, it will be for some other reason such as ease of programming, extensive and well-developed libraries, ease of hiring Python programmers, etc., where Python is better than Go and fast enough.

I've always loved Python and have done a LOT of it (professionally and privately) over many years, but Go has replaced most of it. Having fast, concurrent apps statically compiled into a single executable is a huge improvement for many of my uses of Python, esp. server-side apps and local command line utilities. But I would still prefer Python as a teaching language, for machine learning, for quick one-off tasks (ex: format an ugly chunk of copied data into C++ source code), and possibly for code that I wanted others to write and maintain for me. (Python programmers are easier to hire than Go programmers.)

Many things can be "fixed" if you choose to go to another system. Good developer environments limit the supported tools, languages and packages. This comes from several issues:

* When something goes wrong at 2 a.m., is the developer available going to be able make a reasoned decision how to fix the program?

* Can you hire people with a mix of Python and Go experience?

* If you want performance, why not choose a faster variant of Python so you stay in the same skill set?

* You successfully built a Go program, but did you document your development? Did you set up a standard environment? What about CI/CD and automated testing?

When you leave your position (and you will someday), who is really able to take over managing that software?

> My coworkers who don't know Go understood the code just fine.

Understanding and groking are two different things. I'm sure they looked at the code, nodded their heads that it makes sense; however, I suspect that if you asked one to modify the program with a new feature that they suddenly will see all the things that they don't know, from getting their environments working to subties in the language's mechanics.

Environments are standardized to prevent having these types of issues between workers. Software development is ultimately about supporting the people and business goals in the company.