In a less than optimal world, you might decide to do something less inspired. You might take that break from the C runtime and then just implement threads again, with basically the same semantics, except that they are scheduled in userspace. Your users would be required to implement concurrency in terms of threads, locks and channels, just like they had always been in the past. You might also decide your language should have other classic features like null pointers, default constructors, data races and GOTO, for reasons known only to you. Maybe you would also drag your feet for years on adding generics, despite frequent user requests. You might go do that, in a less than optimal world.
just implement threads again, with basically the same semantics, except that they are scheduled in userspace
To be fair, the Go implementation here is quite interesting since it scales way better than OS threads, so there are fewer downsides to spinning up a ton of threads. So it’s closer to async abstracted behind a threading veneer, like the GREEN functions in the article.
Though the “known only to you” criticisms are absolutely on-point.
Ah. No, keep reading:
(Emphasis on “go” is in the original.)
Lol.
To be fair, the Go implementation here is quite interesting since it scales way better than OS threads, so there are fewer downsides to spinning up a ton of threads. So it’s closer to async abstracted behind a threading veneer, like the GREEN functions in the article.
Though the “known only to you” criticisms are absolutely on-point.
Yeah, Boats’ point there is definitely about semantic correctness rather than performance. Goroutines do indeed have good performance.