> His "sad truth" conclusion is that "Python cannot be super-fast" without breaking compatibility.
A decent case of Python 4.0?
> So, maybe, "a JIT compiler can solve all of your problems"; they can go a long way toward making Python, or any dynamic language, faster, Cuni said. But that leads to "a more subtle problem". He put up a slide with a trilemma triangle: a dynamic language, speed, or a simple implementation. You can have two of those, but not all three.
This trilemma keeps getting me back towards Julia. It's less simple than Python, but much faster (mitigated by pre-compilation time), and almost as dynamic. I'm glad this language didn't die.
I think "Python 4.0" is going to have to be effectively a new language by a different team that simply happens to bear strong syntactic similarities. (And at least part of why that isn't already happening is that everyone keeps getting scared off by the scale of the task.)
Thanks for the reminder that I never got around to checking out Julia.
I definitely agree with this eventually, but for now why not just let developers set `dynamic=False` on objects and make it opt in? This is how Google handles breaking Angular upgrades, and in practice it works great because people have multiple years to prepare for any breaking changes.
Yeah, this is a case of "horses for courses", as you suggest.
I love Python. It's amazing with uv; I just implemented a simple CLI this morning for analyzing data with inline dependencies that's absolutely perfect for what I need and is extremely easy to write, run, and tweak.
Based on previous experience, I would not suggest Python should be used for an API server where performance - latency, throughput - and scalability of requests is a concern. There's lots of other great tools for that. And if you need to write an API server and it's ok not to have super high performance, then yeah Python is great for that, too.
But it's great for what it is. If they do make a Python 4.0 with some breaking changes, I hope they keep the highly interpreted nature such that something like Pydantic continues to work.
I think you're referring to the TTFP (time to first plot) issue (the package manager is top notch). TTFP has been drastically improved with a bunch of optimisations, and then you can pre-compile your project to keep it fast e.g. between running your script with different params.
A decent case of Python 4.0?
> So, maybe, "a JIT compiler can solve all of your problems"; they can go a long way toward making Python, or any dynamic language, faster, Cuni said. But that leads to "a more subtle problem". He put up a slide with a trilemma triangle: a dynamic language, speed, or a simple implementation. You can have two of those, but not all three.
This trilemma keeps getting me back towards Julia. It's less simple than Python, but much faster (mitigated by pre-compilation time), and almost as dynamic. I'm glad this language didn't die.