21–30 of 97 posts
Yea lets ditch everything we learned about modularization in the past 20 years and put everything in one single binary
Yea lets ditch everything we learned about modularization in the past 20 years and put everything in one single binary
Having to rebuild thousands of binaries every time a vulnerability is found in a popular library is seriously hurting Linux distributions. That, and having to handle vendorized dependencies.
Do you have a source for this?
It has HTML templates library, decent error handling, rpc, logging, built-in http server. Many people choose golang for that reason.
I do not quite see the point of this (other than being an exercise). We already have web server that do "logging, tracing, health check, graceful shutdown." I do not care about zero deps, because I only install them once and the deps are taken care of by the package manager. In my opinion, the Go web server only makes sense as part of a Go application as a whole. But a standalone Go web server does not make much sens…
Hi chrisper, you are right! This is just a reminder for me on how to do those things when I start a new app in Go, instead of always google for them.
I do not quite see the point of this (other than being an exercise). We already have web server that do "logging, tracing, health check, graceful shutdown." I do not care about zero deps, because I only install them once and the deps are taken care of by the package manager. In my opinion, the Go web server only makes sense as part of a Go application as a whole. But a standalone Go web server does not make much sens…
To do all of this in just over a hundred lines of code without having to import packages to do it is pretty incredible. It may be just an exercise but it is a very cool one.
I do not quite see the point of this (other than being an exercise). We already have web server that do "logging, tracing, health check, graceful shutdown." I do not care about zero deps, because I only install them once and the deps are taken care of by the package manager. In my opinion, the Go web server only makes sense as part of a Go application as a whole. But a standalone Go web server does not make much sens…
I disagree, I will always prefer projects with the least dependencies given two options with the same feature set. We should always try to strive to lower dependencies when it makes sense.
I build stuff like this for a living. I'd recommend not re-inventing the wheel yourself and using a nice web framework, like Echo (https://github.com/labstack/echo) or Gin (https://github.com/gin-gonic/gin). I prefer Echo due to a cleaner, mockable design, but they're equivalent.
You can throw up that web server in 1/10 the code to do the same thing, and using built-in middleware is less work than writing your own.
I do not quite see the point of this (other than being an exercise). We already have web server that do "logging, tracing, health check, graceful shutdown." I do not care about zero deps, because I only install them once and the deps are taken care of by the package manager. In my opinion, the Go web server only makes sense as part of a Go application as a whole. But a standalone Go web server does not make much sens…
I disagree, I will always prefer projects with the least dependencies given two options with the same feature set. We should always try to strive to lower dependencies when it makes sense.
Maybe, but I think 'when it makes sense', might be 'rarely'. There a 2 ways to avoid dependencies: 1. lean on a batteries-included standard lib as this gist does or 2. write it yourself.
Problem with 1. is standard lib libraries aren't always great, see 'where modules go to die' [1], (examples: httplib/urllib in Python, or the string libraries in PHP). This can stifle innovation and alternatives, unless an alternative with a strong marketing push can arise ('requests' for Python). Sadly, often because the situation isn't 'that bad' (as in the case of PHP) people continue to use poor APIs.
Problem with 2. is you're probably getting an order-of-magnitude fewer brain cycles on code you wrote yourself -- unless you can spend the extra effort to open-source it, and get lucky with popularity/contributors, it's likely to be inferior than a well-maintained 3rd party alternative.
[1] http://www.leancrew.com/all-this/2012/04/where-modules-go-to...
Earlier quoted context omitted.
Hi chrisper, you are right! This is just a reminder for me on how to do those things when I start a new app in Go, instead of always google for them.
I like how you, as the owner of the repo and poster, agreed with me, yet I got -3 points...
> "I think this is likely a useful exercise. That said, I'm not sure I see myself actually using this."
> "We already have web server..."
Yeah, it's subtle, but I think it comes off differently as it's more upfront that doing this may actually have had a use. And both the writer and the reader are involved in the communication: you yourself can only control so much.
Anyway, this is only speculation.
Earlier quoted context omitted.
I disagree, I will always prefer projects with the least dependencies given two options with the same feature set. We should always try to strive to lower dependencies when it makes sense.
If you are using Go to create something, then just use the built in webserver library (as shown in this repo). So that would make this project as a library (not just as an exercise / protoype) useless. Don't you think?