What does battle-tested even mean here. Not handling something as basic as timeouts properly for many years suggests that nobody actually uses built-in server for anything complex standalone, but more likely behind nginx and without direct communications with a hostile world. So it's more like not tested at all. But a decent abstraction over TCPConn with impossible to forget timeouts takes like 15 lines of code and is way more reliable, than using net/http.

Networking packages in Go's standard library are just too poor quality to argue about them. And it's not like they are different here, most languages don't have decent built-it networking libraries either, they usually are developed by 3rd parties as language matures.

> Not handling something as basic as timeouts properly for many years suggests that nobody actually uses built-in server for anything complex standalone, but more likely behind nginx and without direct communications with a hostile world.

Sure, but from what I know, Go actually supports them now. As problems are discovered, they will be dealt with. It saves you reinventing the wheel.

You had suggested writing your own simple HTTP/1.0 implementation. HTTP/1.0 is not enough for talking to the outside world. It lacks vhosts, it lacks keepalive. You lack HTTPS support too without adding your own TLS layer. You would have to use nginx or something in front for it to be ready for the outside world. By your logic, wouldn't Go's own HTTP server be fine, then? It'd certainly be easier.

Go's own http server behind nginx would be fine, until it won't. Which was my whole point. Let's say you have to deal with streaming through the server, you will have to learn the hard way that there is no way to set timeouts there even today.

Must admit I was bitten by the client timeout issue with my first real Go webapp. The thing was getting spidered here and there and would bail due to running out of FDs every couple of days.