3 ms·

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 lack

by zzzcpan 10y ago

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)

bacongobbler 10y ago
Can you elaborate more on some of those production ready defaults the stdlib doesn't have? Genuinely curious.
- zzzcpan 10y ago
  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.
- shadowmint 10y ago
  https://blog.gopheracademy.com/advent-2016/exposing-go-on-the-internet/ https://blog.gopheracademy.com/advent-2016/exposing-go-on-th... covers a number of issues that should be considered.
lox 10y ago
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.
TazeTSchnitzel 10y ago
> 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.
- zzzcpan 10y ago
  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.
  - frou_dh 10y ago
    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.
  - TazeTSchnitzel 10y ago
    > 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.

by zzzcpan 10y ago

bacongobbler 10y ago

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

zzzcpan 10y ago
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.
shadowmint 10y ago
https://blog.gopheracademy.com/advent-2016/exposing-go-on-the-internet/ https://blog.gopheracademy.com/advent-2016/exposing-go-on-th... covers a number of issues that should be considered.

lox 10y ago

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.

TazeTSchnitzel 10y ago

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

zzzcpan 10y ago
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.
- frou_dh 10y ago
  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.
- TazeTSchnitzel 10y ago
  > 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.