> Why do you need that many threads? In micro-service world there are many service which read request over the network (HTTP or some RPC), send multiple reques

> Why do you need that many 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).