[chrisper]

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 sense to me.

[striking]

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.

[chrisper]

I never said it is not a cool exercise. I meant more like it is not something one would download and compile and run it... like it is not a useful tool. Just a cool one. And that is fine.

[striking]

Very few things on Hacker News are such that you can directly download and install them; I don't know why you'd have that expectation. Anything from a full app to a code snippet to a cool article that has nothing to do with tech is welcome here.

[enricofoltran]

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.

[chrisper]

I like how you, as the owner of the repo and poster, agreed with me, yet I got -3 points...

[jasonlotito]

FYI: You'll also get down voted for commenting on the down votes.

https://news.ycombinator.com/newsguidelines.html

[grzm]

I suspect you received down votes because your initial comment comes off as dismissive. A lot of HN members tend towards encouraging constructive criticism rather than only pointing out limitations (especially for Show HNs† which this effectively is) in the interest of facilitating a civil forum. Given the limitations of text (particularly online), it's easy to misinterpret tone. I think you could have said essentially the same thing with some simple rephrasing. For example:

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

† https://news.ycombinator.com/showhn.html

[35bge57dtjku]

Look at all the other gray comments here. Any comment questioning why this is so great appears to be severely triggering the masses.

[dang]

Please don't break the HN guidelines by going on about voting in comments.

https://news.ycombinator.com/newsguidelines.html

[tbrock]

I think this is more of a statement on how batteries beibg included in this language make it easy to build such things without a fuss.

[sergiotapia]

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.

[allover]

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

[013a]

You spend brain cycles trying to navigate and integrate third party libraries, learning their APIs, keeping the dependencies updated.

I'd encourage developers, especially Nodejs devs, to look at their list of dependencies and ask the following two questions about each of them:

1. How long would it take me to replicate this functionality?

2. How often does this functionality need updating?

There is a threshold balanced between both of those questions where, once the numbers pass, it makes sense to bring in dependencies. But I truly believe the "instant gratification" primate part of our brains tends to overestimate the benefit of dependencies and underestimate the long term negatives of them.

Here's a common Nodejs example: Request. Request is used all over many projects. Did anyone who imports it even try to use http.request in the nodejs stdlib? Its actually pretty great. Now, you introduced a new dependency. You made your build process longer. You made your deploy artifact bigger. You've got to keep it up to date. You've got to make sure there aren't security breaches. You've got to learn a new API that, unlike the Nodejs stdlib, is just made by "some guy somewhere" and is horribly documented inside a Github README.

How long would it take me to replicate the functionality of request just using http.request? It depends what parts of request I'm using, but probably very little time. How often does this functionality change? Literally never. Literally never. HTTP/1.1 was finalized decades ago. Request, right now, has 48 open PRs, 560 open issues, was last "released" a couple months ago, and was fixing security issues which were definitely already fixed in stdlib.

But the primate part of your brain says "Eh fuck all that, I'll let future self deal with the negatives of a new dependency, what I want today is an API interface that's, like, 20% easier to use."

[marcus_holmes]

This is what I love about Go, and why I moved away from Node. The culture of fewer dependencies.

I only use the stldlib in Go, and a few packages (like google/uuid) that will become part of the stdlib at some point.

I know exactly what my program is doing, and why.

In Node, I would often hit 100+ dependencies before getting to the actual meat of the thing, and if there was a problem I had no idea where to look in the mess of other people's code. Given the number of PR's on the average node module, and the number of dependencies, I was guaranteed to be importing bugs every time I used an external module. Whether I hit one of those bugs and had to deal with it was a matter of luck. Dealing with bugs in someone else's library is a million times worse than writing the code myself.

[chrisper]

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?

[allover]

This project isn't a library though, it's a gist. Author says it's to remind them how to hook things up.

[weberc2]

I assume this is showing you that you could easily build these things into your own application server. At least that's what I took away.

[gchamon]

If I would use any code as a dependency in a project I am working on, I like it when the dependency I'm adding doesn't come with strings attached (extra deps) as things can get really weird really fast (using awesome bootstrap + icheck for instance)