I imagine there are actual use cases for it but what are programs doing spinning up thousands of threads? I've never seen a program like that. Whatever happened to worker thread pools?
Say you write a server, one thread, one client at a time. Easy peasy, terrible throughput and performance. Well, making it thread-per-client is trivial! Easy peasy, much better throughput and performance, but terrible at scale.
Now you want to scale, so you need to abandon the thread-per-client, everything-is-synchronous-looking model and start doing async I/O the hard way (perhaps with await, perhaps as callback hell). That's a huge refactor / re-write exercise.
But you'd be surprised how many thread-per-client apps exist. It's so easy to write them...
Well say that you're building a micro service that needs to handle a high number of concurrent requests. A server running Go will handle ~100x the traffic of a Python or Ruby app. Your milage will vary depending on the use case, but the difference is huge.
Found out yesterday that even with async in Python someone can sneak in some sync code and totally ruin your day. All you know is your performance is plummeting all across your system and CPU is spiky as hell. Took me most of the day to realize the issue. From now on I’ll start every performance investigation with ‘grep requests’. Problems like this simply don’t exist in Go.
