But gorutines are better than threads when you need you need many (say >100K) of them. Lightweight threads are not unique to Go but in Go they are easy to use and the default way to build network applications. Java is catching up with project Loom but it would never be as easy as Go to use.
> are better than threads when you need many (say >100K) of them
Stackless coroutines are even more efficient for that case, and Rust makes them comparatively easy. (And slated to get even easier in future versions, as the async support is improved further.)
Moreover stackful coroutines/fibers as used in Golang also makes it infeasible to have seamless FFI with the standard C API/ABI, which cuts you off from the bulk of the ecosystem. There are other issues too with having fibers in a C-like systems programming language - see https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p13... for a nice summary of them.
Alef (arguably one of the antecedent of Go) had stackful couroutines/fibers yet it could have had such a seamless FFI to the standard C API/ABI.
The plan9 libthread (which reimplemented the Alef concurrency model for C) did have seamless use of the C API/ABI.
The mechanism was that it had threads and coroutines, a function needing to make use of the C API in a seamless manner would simply run as a thread rather than a coroutine. It was then easy to share data as the CSP model (with channels) worked between both coroutines, threads, and coroutines within a thread.
So if one wishes to use stackful coroutines, and still have that seamless compatibility, an approach mixing the Go and Alef approaches would seem necessary. i.e. the Go migrating coroutines as a default, but with the option to use Alef like thread bound coroutines when necessary.
> The mechanism was that it had threads and coroutines, a function needing to make use of the C API in a seamless manner would simply run as a thread rather than a coroutine.
This reintroduces the colored functions that we were trying to get away from in the first place, by adopting stackful coroutines/fibers. Why not use async at that point? I can understand that Alef didn't, because stackless mechanisms were not well understood at the time. But it's plausible that we can do better.
Stackless coroutines are what every language that has async/await (Js, C#) uses. I've seen them getting a lot of hate here for needing a special kind of method to run in and being less elegant than green threads.
In micro-service world there are many service which read request over the network (HTTP or some RPC), send multiple requests, may be read something from disk, write logs all mixed with some business logic. A significant fraction of time is spend on waiting so a single modern server can handle a large number of parallel connections to the service without saturating hardware resources.
Async allows to do the same (handle many network connections in a single thread) but:
1. It's less ergonomic (less easy to write code) IMHO
2. In pure async if you do a long CPU intensive task in between I/O all other connections in the same thread will wait, which Go solves (at least partially) by using M:N model (pure async is M:1 - connection tied to a particular thread and even if you have many threads you cannot move connections around).
I would not argue that Go concurrency model is the best we can get but it's a good fit for micro-service architecture and a good balance between performance and easy development.
> Linux doesn't even allow you that many file handles.
Not by default but it's easy to rise limits for this and if you are running a loaded server you should not rely on defaults anyway. To get to 100M descriptors you likely need to tune only ulimit (LimitNOFILE in systemd) because default value for fs.file-max is likely large (AFAIR default scaled to the RAM size).
