Hacker News Reader

Comment by zzzcpan | Hacker News Reader

Note, that this is not how anyone should actually write web applications in Go. Standard library doesn't have production ready defaults, in some cases even lacks options for that, and generally offers bad choices in terms of abstractions and performance. And as complexity of your app increases you are going to suffer the consequences.

Safer road for a webapp is to start from a net.TCPConn kind of server with your own tiny HTTP/1.0 parser and a tiny templating engine, your own or a 3rd party one (it's absolutely not hard). Pay attention to synchronization, packages that do implicit synchronization are better left to their owners, avoid unnecessary accidental complexity like that.

(Go user since Go 1.0, speaking from the experience)

View on HN

That statement is incredibly hyperbolic, the defaults work fine for quite considerable scale (many millions of requests a day). Have used golang with http defaults in multiple high volume production deployments and rarely needed tuning.

> Safer road for a webapp is to start from a net.TCPConn kind of server with your own tiny HTTP/1.0 parser

Yet you complain Go lacks "production ready defaults"? Surely the built-in server would be more battle-tested here, and you can use its existing configurability, rather than having to enjoy the pain of implementing timeouts yourself after your server dies.

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.

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.

> 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.

Can you elaborate more on some of those production ready defaults the stdlib doesn't have? Genuinely curious.

By default there are no timeouts in net/http, for example. And you cannot specify them for everything. This has been going on for a long time, they fix one timeout here and there from version to version, as people report leaks, but to this day can't seem to cover all the bases.

https://blog.gopheracademy.com/advent-2016/exposing-go-on-th... covers a number of issues that should be considered.

Reply on news.ycombinator.com