Hacker News Reader

Comment by doublerebel | Hacker News Reader

So, once upon a time I wanted to associate information with http connections (as I am accustomed to in every other language I've ever written) just to enable proper http keepalive and debugging through a proxy written in Go.

Ended up with this. [0]

Turns out the Go authors don't think you should do this so I had to majorly alter and recompile the stdlib.

I still appreciate many go tools and the cross platform single binaries that work great on Solaris/Illumos. But in many cases the strong opinions of Go authors really stand in the way of getting work done.

[0]: https://github.com/doublerebel/publictransport

View on HN

These days you have http requests with context (I think starting from Go 1.8), see https://golang.org/pkg/net/http/#Request.Context

Seems like you got work done by altering the stdlib because it was approachable enough to alter. I don't see what the complaint is here.

If you actually take a look at the many changes that had to be made due to the uncreative limitations imposed by Go, you'll see that it was was neither approachable nor maintainable. I'm just stubborn and found it hard to believe it would actually take that much work until I tried it.

This is supported by the fact that contexts have been added, and I won't be surprised to see Go reverse more of their decisions as the language grows and devs prioritize shipping over Go dogma.

That's more a criticism of the standard HTTP server, which is a bit of a black box, apparently intentionally. There's nothing wrong with writing your own server to make up for it's limitations.

except for the fact that you shouldn't have to write your own server?

But that depends on what you're trying to accomplish. It's intended as a high-level, general-purpose server. It will always lack features if you go advanced enough.

Why not? Plenty of languages don't come with one built in at all, or not one widely used in production (e.g. Python's http.server, there are a heap of other Python web servers out there).

They count 24 lines of code as "infuriating amount of code to write". Why do you think they would interested in writing a web server ?

To be fair, 24 lines for something you know should be doable in only a few (or one!) is pretty darn frustrating.

I was counting less the 50 lines as "few lines".

when you set out to solve a particular problem, do you really think its a worthwhile use of your time and effort to create a webserver? Mind you i'm not talking so much about "built-in" webservers than I am about reusing an existing, battle tested one from a 3rd party (e.g. OSS) so you can focus on the actual problem your trying to resolve.

If the problem I'm trying to solve is "I want a better webserver", then yes :) That's a little tongue-in-cheek, but I assume is more or less the motivation behind all web servers in use today; otherwise we'd all be using httpd or something.

Yes, if you want to build a better webserver, go right ahead. But I think we're in agreement, that you shouldn't be reinventing wheels that you are not purposefully trying to reinvent. If we always started from scratch, nobody would get anything done.

Reply on news.ycombinator.com