Live data from Hacker News

Reverting the incremental GC in Python 3.14 and 3.15

discuss.python.org

61–70 of 134 posts

Re: Reverting the incremental GC in Python 3.14 and 3.15

#61
post #50
post #43

Earlier quoted context omitted.

We should all go back to writing assembly

No we should write one of the many modern programming languages that handle certain projects way better, including kotlin, go, or Java. The only things python is best in class at are scripting and as a harness for high performance c++ or fortran.

What about the projects that python handles better?

Re: Reverting the incremental GC in Python 3.14 and 3.15

#62
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.

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.

The only thing Go has going for it was getting lucky with Docker and co, and UNIX/Plan 9/Inferno pedigree.

Now we're stuck with it in anything CNCF related.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#63
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?

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.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#64

Earlier quoted context omitted.

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 .

I'm currently in a .NET shop so not an issue for me, makes me wonder if Python will eventually adopt the concept of LTS releases, this could have been avoided as an issue if it was part of a non-LTS release.

Re: Reverting the incremental GC in Python 3.14 and 3.15

#65
post #62

Earlier quoted context omitted.

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.

The only thing Go has going for it was getting lucky with Docker and co, and UNIX/Plan 9/Inferno pedigree. Now we're stuck with it in anything CNCF related.

I like my programming language flame wars just as much as the next guy but Go is a really easy language to get started with, while also being very fast. It's not just luck

Re: Reverting the incremental GC in Python 3.14 and 3.15

#66
post #28
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?

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.

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)

Re: Reverting the incremental GC in Python 3.14 and 3.15

#67

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.

But that day is not today .. unless you are working for microslop or clownflare ? Half-kidding, sorry :)

Re: Reverting the incremental GC in Python 3.14 and 3.15

#68

Earlier quoted context omitted.

Regardless of whether golang and python are actually equally simple, python certainly has the reputation of being easier to write and read than almost any other language. That is a big part of its popularity.

Python is not really simple though, the semantics are actually quite bonkers. It just has "simple"-looking syntax, but that only helps you for trivial programs where the bonkers semantics does not get in the way.

What about the semantics are bonkers in your opinion?

Re: Reverting the incremental GC in Python 3.14 and 3.15

#69
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.

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.

What? If you are talking web development, .Net is just about the same as Go. It's 100% Java OOP type writing but result is same, very performant API server.

Sure, Rust is completely different beast with different target system.

Post reply on HN