I use go net/http every day, in production. I trust it, but NGINX provides so much more battle tested functionality out of the box.
I use go net/http every day, in production. I trust it, but NGINX provides so much more battle tested functionality out of the box.
How do you know how many lines are required to configure hypothetical middleware?
> No go gets
How is static compilation worse than `apt-get install` or `docker run`?
> No middleware
It's another process... why would running another process be better than middleware?
> it's well tested, mature and backed by software that powers a majority of the web.
Granted. It seems like this is the only clear win for NGINX, and it may well change if Go libraries mature. Time will tell.
Primarily through experience. Happy to be shown otherwise. Middleware usually takes a bit more configuration than that.
> Granted. It seems like this is the only clear win for NGINX, and it may well change if Go libraries mature. Time will tell.
We can quibble over whether it's the "only" win, but even so, it's a very, very big win. It's a single point of failure that handles a lot of features you'd have to replicate with various packages that lack the kind of support, maturity and community that NGINX has.
Sorry but I'm not going to be writing ansible code that modifies structs inside of some program then compiles said program. No thank you that sounds like crazy town. Also other sysadmins and infrastructure engineers will actually know how things work and won't have to go reading the source code for some crazy Go app program at 2am that also is a webserver for some reason?
Separation of concerns, use it!!
The discussion is scoped to a single Go application. No one is proposing replacing NGINX with Go (or anything else) for JVM apps.
> won't have to go reading the source code for some crazy Go app program at 2am that also is a webserver for some reason?
This is a rephrasing of the question I posed earlier--is it easier to manage configuration in Go source code or NGINX config files.
> Separation of concerns, use it!!
Concerns can be separated without being in distinct processes or implemented by distinct programmers or implemented in distinct programming languages.