Earlier quoted context omitted.
And if people want python with java, there's always Jython.
jython has been basically unmaintained for quite some time
Reverting the incremental GC in Python 3.14 and 3.15
21–30 of 134 posts
Re: Reverting the incremental GC in Python 3.14 and 3.15
#22Re: Reverting the incremental GC in Python 3.14 and 3.15
#23A couple of services looked like they had a memory leak. Memory was continuously increasing over time. Thanks to Python 3.14, we were able to use memray to understand what was going on. Those services were recreating HTTP clients (aiohttp) for every inbound request, and memory allocated by the downstream SSL lib was growing faster than it was being released.
We ended up rolling back to 3.13, which fixed the issue. I'll try again with 3.14.5.
Re: Reverting the incremental GC in Python 3.14 and 3.15
#24In the world of AI written code, Python just doesn’t make sense. Converted about 100k lines in the last few months to golang and the performance is life changing. Curious if we will see global Python adoption fall by 75% or more in the next few years.
Re: Reverting the incremental GC in Python 3.14 and 3.15
#25.NET seems to have regularly changed the garbage collector over the years and I do not remember any similar surprises in production. I wonder why they have had better experience? I thought that by now dynamic garbage collection was a known quantity so that making changes, outside of out right bugs, is fairly safe and predictable?
I’ll confess the reason it hit us so hard is because the code quality was so low and wasteful on allocations that it didn’t hide the problem as well as previous versions.
Re: Reverting the incremental GC in Python 3.14 and 3.15
#26"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?
Re: Reverting the incremental GC in Python 3.14 and 3.15
#27Earlier quoted context omitted.
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?
And if people want python with java, there's always Jython.
Re: Reverting the incremental GC in Python 3.14 and 3.15
#28"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?
Re: Reverting the incremental GC in Python 3.14 and 3.15
#29.NET seems to have regularly changed the garbage collector over the years and I do not remember any similar surprises in production. I wonder why they have had better experience? I thought that by now dynamic garbage collection was a known quantity so that making changes, outside of out right bugs, is fairly safe and predictable?
So I think it was not a big problem for .Net because it gave you enough control over GC, and because people tested their code before putting it in production.
Re: Reverting the incremental GC in Python 3.14 and 3.15
#30I think reverting is not problem per se, but releasing a highly problematic version without proper testing in such an essential component is.