[RcouF1uZ4gsC]

I don’t think Coroutines would fit in with Go. There is a huge emphasis on simplicity. Coroutines add a massive amount of complexity. In addition, goroutines provide the best parts of Coroutines - cheap, easy to use, non-blocking operations - without a lot of the pain pints such as “coloring” or functions and issues with using things like mutexes.

Just the question of whether one should use a goroutine or a coroutine adds complexity.

[badrequest]

There are plenty of complicated things in Go, IMHO where it shines best is judiciously providing incredibly nice interfaces atop the complicated things.

[bb88]

Having coded in go professionally, I disagree. Go abstractions leak in weird and unexpected ways that are surprisingly different to it's C/C++/Java predecessors.

Goroutines were kind of the raison detre' for using go. But using them wasn't simple, and instead often goroutines brought their own issues. See here:

https://songlh.github.io/paper/go-study.pdf

Often a programming language takes a first guess at the problems they want to solve, and often get them wrong. C++ is probably the most notable language in this category here.

That said, I do appreciate an attempt to improve programming languages even if it undermines the primary feature of the language itself.

[talideon]

There's no colouring here. These are synchronous coroutines.