[lossolo]

In what world is the cost of 2.5 GB of RAM per 1 million connections an issue? Are you telling me there's a service in this world handling, for example, 100 million active connections, and they can't afford 250 GB of RAM? It's not the 90's anymore.

And we're talking about a naive microbenchmark. If you were actually building a service like that in Go (millions of active connections) and you were very concerned about memory usage, you wouldn't be naive enough to use a goroutine for every connection. Instead, you would use something like gnet or another solution based directly on epoll events, combined with a worker pool.

[yencabulator]

> If you were actually building a service like that in Go (millions of active connections) and you were very concerned about memory usage

Or, much more likely, pay a few tens of dollars per month for a second server and start scaling out.

[OutOfHere]

Go is a friendly language and it is well liked, but it is inappropriate when the absolute best performance saves more money than the additional developer salaries needed to write it in a higher performance language. An example is for deep learning or other big numerical work, where you'd be wasting expensive hardware resources if using Go. Perhaps the one million concurrent users will however be fine with Go.