[zemo]

>For example, suppose those 100,000 goroutines were network servers and a hostile client could manipulate the connection to block the routine while it was consuming 400 KiB of stack.

hmm so you're saying a request causes 400KB to be allocated, and an attacker hits your server with 100k requests designed to cause your server to stall? The same criticism could be leveled against... any system where a requestor can allocate memory and stall a handler that is independent of the incoming request loop. How would this be different in a different concurrency model?

>Space is almost never a reason to use coroutines over threads.

I wouldn't necessarily say so. I have a polling service that uses a few thousand standing goroutines. The memory overhead for each individual goroutine is so low that I can just spawn them casually. Each goroutine only actually does work for a few seconds every few minutes; the vast majority of the time, each goroutine is spent sleeping. For this type of problem, I find that organizing things with goroutines and channels makes my code very easy to reason about. That, to me, is the biggest win of Go's concurrency model; that it's very easy to reason about.

[chime]

> I find that organizing things with goroutines and channels makes my code very easy to reason about. That, to me, is the biggest win of Go's concurrency model; that it's very easy to reason about.

Absolutely agree. I just wish the net.Dial calls would let me specify a timeout and wouldn't hang around for 3mins in case something is down.

[0xABADC0DA]

How would this be different in a different concurrency model?

That was actually the point. You have the same space considerations. Being coroutine instead of native thread is just a small constant factor... if this factor is important then you are almost certainly doing it wrong.