Live data from Hacker News

Reverting the incremental GC in Python 3.14 and 3.15

discuss.python.org

51–60 of 134 posts

Re: Reverting the incremental GC in Python 3.14 and 3.15

#51

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

For personal projects, yes. For code going into production, you still need human code review, and that has to happen in a language that the humans you've hired are comfortable with. One day, we'll all be YOLOing vibe code straight into production, but that day is not today.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#52

I'm genuinely surprised that python change was even possible without PEP

Makes ya miss having a BDFL. Dang I didn't realize he's 70 now. https://en.wikipedia.org/wiki/Guido_van_Rossum

I wouldn’t recommend running the latest Python in prod. Honestly 3.x.7 releases are the most mature .

Re: Reverting the incremental GC in Python 3.14 and 3.15

#54

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

I think we'll eventually be generating machine code directly. But until then we should be using code that our team can actually read and understand. If you know go, then that works you, Not everyone does.

Doubt it. LLMs will always be more expensive per-token than compilers, and high level languages need fewer tokens than machine code. Also, type systems, warnings, overlap with natural language in names - those are very useful.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#55
post #49

Earlier quoted context omitted.

One thing Microsoft does really well is eating its own dogfood and Microsoft feeds a ton of .Net dogs. So any change to GC starts with massive .Net MSFT code base so they get extremely good telemetry back about any downsides and might be able to fix it in time.

Did really well, unfortunately. There is almost no dog fooding on Windows development since version 8, Typescript team rather rewrite the compiler in Go, Azure has plenty of Go, Rust and Java projects alongside .NET.

Microsoft does use Go/Rest/Java in places but they still have a ton of .Net.

Windows Development is not "We are not dogfooding", it's that incentives are misaligned with customer wants.

.Net team incentives are aligned with customer wants, provide a language that is highly performant and easy enough to write.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#56

I'm genuinely surprised that python change was even possible without PEP

It's not a change to the language, it's a change to the cpython runtime

PEPs aren't necessarily just for language changes, e.g https://peps.python.org/pep-0436/ which is largely a CPython implementation detail.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#57
post #13

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

jpype and graalpy are life.

jython went EOL.with python 2 going EOL.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#58
post #49

Earlier quoted context omitted.

Did really well, unfortunately. There is almost no dog fooding on Windows development since version 8, Typescript team rather rewrite the compiler in Go, Azure has plenty of Go, Rust and Java projects alongside .NET.

Microsoft does use Go/Rest/Java in places but they still have a ton of .Net. Windows Development is not "We are not dogfooding", it's that incentives are misaligned with customer wants. .Net team incentives are aligned with customer wants, provide a language that is highly performant and easy enough to write.

Oh, they really don't dogfood Windows development any longer, regardless of the incentives.

I have my WinRT 8, UAP 8.1, UWP 10, Project Reunion, .NET Native, C++/CX, C++/WinRT, XAML Islands, XAML Direct, WinUI 2.0, WinUi 3.0, WinAppSDK and what not scars to prove how they aren't dog fooding any piece of it in any meaningful manner.

Heck they keep talking about C++ support in WinUI 3, as if the team hasn't left the project and is now playing with Rust instead.

They managed that plenty of early WinRT advocates became their hardest critics, while not believing anything else they put out, like now this Windows K2 project.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#59
post #19
post #12

Earlier quoted context omitted.

I think humans are still accountable for the code generated by agents. You are free to switch language but you still need to understand it.

With a similar amount of experience with both languages I found Go much easier to read. I've always been a bit miffed why Python is seen as easy to read for experienced developers. I get the syntax is good for short code or people with little experience but my experience is those readability benefits went away quickly with time or complexity.

Any language that uses error codes instead of exceptions is a non-starter for me. Produces code that craps all over the happy path.

Python has a different problem: it is slow as f---. I did a micro benchmark comparison against 5 other languages in preparation for my python replacement language. Outside of dictionary lookups, it is 50-600 times slower than C depending on the workload.

Go, Rust etc are fine. They land at 1.25-3x slower than C. But I prefer the readability of python minus its dynamic nature.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#60
post #49

Earlier quoted context omitted.

One thing Microsoft does really well is eating its own dogfood and Microsoft feeds a ton of .Net dogs. So any change to GC starts with massive .Net MSFT code base so they get extremely good telemetry back about any downsides and might be able to fix it in time.

Did really well, unfortunately. There is almost no dog fooding on Windows development since version 8, Typescript team rather rewrite the compiler in Go, Azure has plenty of Go, Rust and Java projects alongside .NET.

Well, .NET is just not in the same class as Go and Rust.

Go is, essentially, nearly perfect at what it does - even if the language itself leaves much to be desired and would ideally be much safer.

Microsoft should up their game. They have a few research languages in development.

They've always been great with languages. Hopefully, they rise to the occassion.

Post reply on HN