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.
Reverting the incremental GC in Python 3.14 and 3.15
61–70 of 134 posts
Re: Reverting the incremental GC in Python 3.14 and 3.15
#62Earlier 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.
Now we're stuck with it in anything CNCF related.
Re: Reverting the incremental GC in Python 3.14 and 3.15
#63Earlier 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.
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
#64Earlier 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 .
Re: Reverting the incremental GC in Python 3.14 and 3.15
#65Earlier 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.
Re: Reverting the incremental GC in Python 3.14 and 3.15
#66Earlier 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.
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
#67In 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
#68Earlier 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.
Re: Reverting the incremental GC in Python 3.14 and 3.15
#69Earlier 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.
Sure, Rust is completely different beast with different target system.
Re: Reverting the incremental GC in Python 3.14 and 3.15
#70Python is such a mess.