4 ms·

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

"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

winrid 5mo ago
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?
- sigmoid10 5mo ago
  And if people want python with java, there's always Jython.
  - brokensegue 5mo ago
    jython has been basically unmaintained for quite some time
    - sigmoid10 5mo ago
      Well, they never made the jump to Python 3. But shipping 2.7 interpreters in 2024 was quite an achievement on its own. So their users already know this pain. And from my experience in academia, python 2.7 and java 8 will probably be used for another 20 years before the last machine running that stuff burns out.
  - arikrahman 5mo ago
    Jython is unmaintained, I'd recommend Clojure. Use python libraries and code while seamlessly targeting the JVM.
  - brian_herman 5mo ago
    Graal vm has support for python 3 unfortunately it’s funded by oracle.
    - wavemode 5mo ago
      If it makes you feel any better (it probably doesn't), the development of OpenJDK and the Java language itself is also mostly funded by Oracle
    - pjmlp 5mo ago
      Java is funded by Oracle, all of it. People parrot to use OpenJDK without understanding it is mostly Oracle employees working on it. And if you dislike Oracle, the other minor contributors are Red-Hat, IBM, SAP, Microsoft, Alibaba, Azul,... which for many HNers are the same.
  - froh 5mo ago
    jpype and graalpy are life. jython went EOL.with python 2 going EOL.
- stackskipton 5mo ago
  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.
- graemep 5mo ago
  Resistance from anyone who matters to the developers?
- pron 5mo ago
  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.
  - JackSlateur 5mo ago
    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)
    - coldtea 5mo ago
      >As far as I know, java has 7 GC implementations, none of which are perfect, all of which have drawbacks Compared to Python's, all of them are beyond perfect. And 99.9% of the time you don't even need to use anything but the default.
      - refulgentis 5mo ago
        > Compared to Python's, all of them are beyond perfect. I somehow understand the situation less after reading this. Is Python's GC bad, or are there cyclic reference issues? Is it possible to detect cyclic references perfectly? What does beyond perfect mean? If we have 7 and 0.1% of the time you need one of the 6 that is non-default, how do we choose? Is the understated version of "Compared to Python's, all of them are beyond perfect" "I think Java's are great"? If not, what about Python's impl makes it so lackluster to any of 7 of Java's?
        murderfs 5mo ago
        > Is Python's GC bad, or are there cyclic reference issues? Unless you're being pedantic and including reference counting without cycle detection as GC, if your GC has cyclic reference issues, your GC is bad. > Is it possible to detect cyclic references perfectly? Yes? That's the entire point of tracing GC. You have some set of root objects that you start with (globals, objects on thread stacks, etc.) and then you mark every object that's reachable from them. Anything that's not reachable is garbage, even if there are cycles within them.
- davidkwast 5mo ago
  It is the same for me. Predicability is better than any optimization.
- zozbot234 5mo ago
  Why not just use Go? It has a proper concurrent, non-moving GC that, AIUI, has not been associated with sudden memory spikes.
  - brokencode 5mo ago
    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.
  - egl2020 5mo ago
    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.
  - LtWorf 5mo ago
    It's a tradeoff. Go programs are extremely slow at starting up for example.
    - bmitc 5mo ago
      That doesn't matter for anything other then CLIs.
      - AlecSchueler 5mo ago
        Some people are writing CLIs
        bmitc 5mo ago
        Yes, of course, but I took the conversation to be centered around backend uses cases. What CLI is experiencing garbage collection issues like that in this discussion?
    - CamouflagedKiwi 5mo ago
- bmitc 5mo ago
  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.?
- CamouflagedKiwi 5mo ago
  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.
bmitc 5mo ago
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?
- mirashii 5mo ago
  What language that is actually used 40 years after release isn't undergoing big, fundamental changes? Java? Nope, you're getting a fundamental change in Valhalla C++? Nope, new language edition every few years with fundamental changes C? C23 has a number of fairly fundamental changes, expect more in the next language revision I think your sense of causality is backwards here. These languages are getting fundamental changes because they're being widely used. That is what motivates and drives the change. Languages with no users don't need to change.
  - adrian_b 5mo ago
    As you say, any widely used language gets fundamental changes from time to time. But most such languages handle much better the compatibility with legacy applications. Python is the main culprit in most cases when I see conflicts between various software packages that insist to use only a specific version of their dependencies. This is why I have to keep installed many versions of Python, and the Linux distribution that I use must take care to prevent interference between those Python versions.
  - bmitc 5mo ago
    > Languages with no users don't need to change. That's fine, but that's clearly not what I'm talking about. Languages like F#, Elixir, etc. don't undergo fundamental changes. Yes, every language evolves. But for Python, we're talking about grafting literally fundamental stuff on top of a language not designed for any of these things. For example, if someone went and redesigned Python to solve its warts, you'd basically end up with F#.

winrid 5mo ago

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?

sigmoid10 5mo ago
And if people want python with java, there's always Jython.
- brokensegue 5mo ago
  jython has been basically unmaintained for quite some time
  - sigmoid10 5mo ago
    Well, they never made the jump to Python 3. But shipping 2.7 interpreters in 2024 was quite an achievement on its own. So their users already know this pain. And from my experience in academia, python 2.7 and java 8 will probably be used for another 20 years before the last machine running that stuff burns out.
- arikrahman 5mo ago
  Jython is unmaintained, I'd recommend Clojure. Use python libraries and code while seamlessly targeting the JVM.
- brian_herman 5mo ago
  Graal vm has support for python 3 unfortunately it’s funded by oracle.
  - wavemode 5mo ago
    If it makes you feel any better (it probably doesn't), the development of OpenJDK and the Java language itself is also mostly funded by Oracle
  - pjmlp 5mo ago
    Java is funded by Oracle, all of it. People parrot to use OpenJDK without understanding it is mostly Oracle employees working on it. And if you dislike Oracle, the other minor contributors are Red-Hat, IBM, SAP, Microsoft, Alibaba, Azul,... which for many HNers are the same.
- froh 5mo ago
  jpype and graalpy are life. jython went EOL.with python 2 going EOL.
stackskipton 5mo ago
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.
graemep 5mo ago
Resistance from anyone who matters to the developers?
pron 5mo ago
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.
- JackSlateur 5mo ago
  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)
  - coldtea 5mo ago
    >As far as I know, java has 7 GC implementations, none of which are perfect, all of which have drawbacks Compared to Python's, all of them are beyond perfect. And 99.9% of the time you don't even need to use anything but the default.
    - refulgentis 5mo ago
      > Compared to Python's, all of them are beyond perfect. I somehow understand the situation less after reading this. Is Python's GC bad, or are there cyclic reference issues? Is it possible to detect cyclic references perfectly? What does beyond perfect mean? If we have 7 and 0.1% of the time you need one of the 6 that is non-default, how do we choose? Is the understated version of "Compared to Python's, all of them are beyond perfect" "I think Java's are great"? If not, what about Python's impl makes it so lackluster to any of 7 of Java's?
      - murderfs 5mo ago
        > Is Python's GC bad, or are there cyclic reference issues? Unless you're being pedantic and including reference counting without cycle detection as GC, if your GC has cyclic reference issues, your GC is bad. > Is it possible to detect cyclic references perfectly? Yes? That's the entire point of tracing GC. You have some set of root objects that you start with (globals, objects on thread stacks, etc.) and then you mark every object that's reachable from them. Anything that's not reachable is garbage, even if there are cycles within them.
davidkwast 5mo ago
It is the same for me. Predicability is better than any optimization.
zozbot234 5mo ago
Why not just use Go? It has a proper concurrent, non-moving GC that, AIUI, has not been associated with sudden memory spikes.
- brokencode 5mo ago
  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.
- egl2020 5mo ago
  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.
- LtWorf 5mo ago
  It's a tradeoff. Go programs are extremely slow at starting up for example.
  - bmitc 5mo ago
    That doesn't matter for anything other then CLIs.
    - AlecSchueler 5mo ago
      Some people are writing CLIs
      - bmitc 5mo ago
        Yes, of course, but I took the conversation to be centered around backend uses cases. What CLI is experiencing garbage collection issues like that in this discussion?
  - CamouflagedKiwi 5mo ago
bmitc 5mo ago
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.?
CamouflagedKiwi 5mo ago
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.

bmitc 5mo ago

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?

mirashii 5mo ago
What language that is actually used 40 years after release isn't undergoing big, fundamental changes? Java? Nope, you're getting a fundamental change in Valhalla C++? Nope, new language edition every few years with fundamental changes C? C23 has a number of fairly fundamental changes, expect more in the next language revision I think your sense of causality is backwards here. These languages are getting fundamental changes because they're being widely used. That is what motivates and drives the change. Languages with no users don't need to change.
- adrian_b 5mo ago
  As you say, any widely used language gets fundamental changes from time to time. But most such languages handle much better the compatibility with legacy applications. Python is the main culprit in most cases when I see conflicts between various software packages that insist to use only a specific version of their dependencies. This is why I have to keep installed many versions of Python, and the Linux distribution that I use must take care to prevent interference between those Python versions.
- bmitc 5mo ago
  > Languages with no users don't need to change. That's fine, but that's clearly not what I'm talking about. Languages like F#, Elixir, etc. don't undergo fundamental changes. Yes, every language evolves. But for Python, we're talking about grafting literally fundamental stuff on top of a language not designed for any of these things. For example, if someone went and redesigned Python to solve its warts, you'd basically end up with F#.