Comment by EdiX

What a strange article. Goroutines definitely do have their downsides, they aren't hard to find either, but nothing he talks about here is actually a downside of goroutines. Also for some reason almost every reference he has is from 2016.

> Further, goroutines' lack of their stack ancestry means they can't natively give out the nice stacktraces found in other languages, though there are a lot of workarounds, to be sure.

I wish he was more speific here, what's "nice" about stacktraces in other languages that is lacked by Go? I really don't get it, it seems to me that they are the same, maybe I'm missing something. There's even a mechanism to record goroutine ancestry [1] but it's from 2018, past this article's knowledge cutoff date maybe?

> Because of this stack disconnection of parents and children, it really becomes impossible to have exceptions

But panics use the exact same mechanism as exceptions? They are not used in the same way as exceptions but it isn't because of any technical limitation of goroutines, it's mostly about what's idiomatic in the language.

His whole example about a panic causing a resource leak, as far as I can tell the difference is that in java an uncaught exception will only close its thread while in go the whole program crashes. You can definitely argue for both behavior as being better (IMO it really depends on the application), but it doesn't have anything to do with how goroutines are implemented.

> This highlights a key difference between cooperative scheduling and OS-level scheduling: OS-level threads can be stopped at any time, while cooperatively scheduled coroutines cannot

Goroutines are actually scheduled preemptively since 2020 [2], again this is probably beyond the knowledge cutoff date of the article. This isn't surfaced to the user however, you still can't stop a goroutine at an arbitrary point. But it doesn't have anything to do with the way goroutines are implemented, it's because it is a design decision to not allow users to do that.

[1] https://github.com/golang/go/issues/22289 [2] https://go.dev/doc/go1.14