Comment by davidkwast
1 day ago
"Python 3.14 shipped with a new incremental garbage collector. However, we’ve had a number of reports of significant memory pressure in production environments.
We’ve decided to revert it in both 3.14 and 3.15, and go back to the generational GC from 3.13."
Sounds the right move for me
The main benefit of python to me is that while slow, it's predictable. I do think they're going to get a lot more resistance to adding JITs, moving GCs, etc. it will become java with a million knobs to tune. If people want a JIT'd python just use pypy, right?
Java lost almost all those knobs a while ago (I mean they're there, but you're better off relying on the defaults). The modern GCs have one or at most two knobs remaining, and even that will become unnecessary next year. As to predictablity, you get maximal pause time of well under 1ms for heaps up to 16TB.
The max pause time thing is a meme :) I have gotten multi second pause times with ZGC. It depends on what hardware you run it on.
2 replies →
As far as I know, java has 7 GC implementations, none of which are perfect, all of which have drawbacks
Lately, they seems to work with CRIU, various heuristics, multi-stage in-process bytecode compilation ..
Java is a mess, they are working hard to avoid fixing their issue (that nobody else have, so fixes are available)
5 replies →
Next year? Do tell
1 reply →
As Python using SRE and supporting Python Flask apps, most of us would love JIT in Python assuming it pretty much drop in replacement.
PyPy doesn't have the support it needs and is stuck on 3.11.
PyPy is not looking healthy right now - it's several versions behind in support and, while it's not dead, it looks like it might be settling down for a rest.
Obviously it's not easy to move the whole language of a big codebase, but I feel a lot of this stuff (fiddling with GC, JITing, type hints, and I'm dubious about the free-threading stuff) tries to take Python somewhere it isn't really good at, and if that's what you want, you really want a different language.
It is the same for me. Predicability is better than any optimization.
Why not just use Go? It has a proper concurrent, non-moving GC that, AIUI, has not been associated with sudden memory spikes.
For a new project, teams can decide whether to use Go, but there are many millions of lines of existing Python servers out there.
Not to mention that there are differences in ecosystem, familiarity, and ergonomics that may make a team want to stick with Python.
“Just use Go” is not really actionable advice in most cases.
Libraries. I use both languages, and a survey of what libraries are available is part of picking an implementation language when starting a greenfield project.
It's a tradeoff. Go programs are extremely slow at starting up for example.
3 replies →
And if people want python with java, there's always Jython.
Graal vm has support for python 3 unfortunately it’s funded by oracle.
2 replies →
jython has been basically unmaintained for quite some time
1 reply →
Jython is unmaintained, I'd recommend Clojure. Use python libraries and code while seamlessly targeting the JVM.
jpype and graalpy are life.
jython went EOL.with python 2 going EOL.
In what way do you feel Python is predictable, especially in comparison to other languages one would build a backend system in?
It's predictable vs Rust, C#, F#, Elixir, Go, etc.?
Resistance from anyone who matters to the developers?
Why are people still building systems on top of a language that continually undergoes fundamental changes nearly 40 years after release? Is this not the strongest indication that this language is not well designed, it is unstable, and encounters many issues that flat out don't exist in other high level languages?