6 ms·

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 pr

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 https://github.com/doublerebel/publictransport

dvirsky 9y ago
These days you have http requests with context (I think starting from Go 1.8), see https://golang.org/pkg/net/http/#Request.Context https://golang.org/pkg/net/http/#Request.Context
lobster_johnson 9y ago
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.
- meesterdude 9y ago
  except for the fact that you shouldn't have to write your own server?
  - pebers 9y ago
    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).
    - codegladiator 9y ago
      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 ?
      - meesterdude 9y ago
        To be fair, 24 lines for something you know should be doable in only a few (or one!) is pretty darn frustrating.
        codegladiator 9y ago
        I was counting less the 50 lines as "few lines".
    - meesterdude 9y ago
      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.
      - pebers 9y ago
        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.
        meesterdude 9y ago
        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.
  - lobster_johnson 9y ago
    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.
ghthor 9y ago
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.
- doublerebel 9y ago
  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.

dvirsky 9y ago

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

lobster_johnson 9y ago

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.

meesterdude 9y ago
except for the fact that you shouldn't have to write your own server?
- pebers 9y ago
  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).
  - codegladiator 9y ago
    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 ?
    - meesterdude 9y ago
      To be fair, 24 lines for something you know should be doable in only a few (or one!) is pretty darn frustrating.
      - codegladiator 9y ago
        I was counting less the 50 lines as "few lines".
  - meesterdude 9y ago
    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.
    - pebers 9y ago
      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.
      - meesterdude 9y ago
        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.
- lobster_johnson 9y ago
  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.

ghthor 9y ago

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.

doublerebel 9y ago
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.