[btbuilder]

This is fantastic progress for CPython. I had almost given up hope that CPython would overcome the GIL after first hitting its limitations over 10 years ago.

That being said I strongly believe that because of the sharp edges on async style code vs proper co-routine-based user threads like go-routines and Java virtual threads Python is still far behind optimal parallelism patterns.

[rowanG077]

Aren't go-routines the worst of all worlds? Sharp edges, undefined behavior galore? At least that was my takeaway when last using about 5 or 6 years ago. Did they fix go-routines in the meantime?

[btbuilder]

It’s hard to answer without specifics but languages shouldn’t require you to determine whether it’s safe to use an api in an async context or whether it will hang your app. I imagine some of the sharp edges you might have run into are because go has real parallelism and you have to address data sharing.

[int_19h]

The sharp edges in Go are when you try to use the built-in mechanisms that are supposed to replace data sharing - e.g. channels - only to discover the numerous footguns that abound there.

And then there's patently stupid design decisions like using raw slices as collections and the maybe-change-maybe-copy semantics of append() that don't make it easier to reason about shared data when it needs to be shared.

[weakfish]

I like them, but I’m doing pretty simple back/end dev in Go, just microservices.