Hacker News Reader

Comment by revelation | Hacker News Reader

The new software relies heavily on the Go net/http implementation of a HTTP server. That is arguably a very very big chunk of the complexity in a HTTP download server.

So it leaves a bad taste when the presentation mocks the original C++ implementation while the Go solution only works because there is a fully functional high performance HTTP server already in the standard library.

There is not a single slide that tells us it may not be a good idea to rely on the standard library for such high-level functionality. Thats why I linked to the bug. A normal user has very little options when it turns out theres a bug in the standard library, other than to report it and wait for you to fix it. The problem is exacerbated since standard library and language versions are tightly coupled.

View on HN

>other than to report it and wait for you to fix it.

Go team is very welcome patches from the external contributors: http://golang.org/doc/contribute.html

No need to wait, you can fix it and have your patch accepted (after a code review).

After that, there's not such a difference between an HTTP server in the standard vs a third-party library

Not to mention it's trivial to maintain a fork of the Go stdlib thank to its permissive license.

Lol, anyone who says 'it's trivial to maintain a fork' about anything has obviously never done so - especially when suggesting in the same sentence that the licence of all things is one of the harder issues when maintaining a fork.

It wasn't meant as a fully maintained fork. Look at it as a set of patches on top of the stdlib.

As for the license, it does matter since with the GPL you'd be stuck and it turns out that there's some debate with the LGPL as well (IANAL).

For most things go is used for right now, you'd normally not run into issues with distribution as defined by LGPL and GPL? (If you use it to deploy something as a service).

Anyway how would the GPL make a difference to your forking of the std lib? Either you link to the standard lib and all your code (that is linked into that binary and distributed as such) falls under the GPL, or you don't -- whether you distribute a patch (set) doesn't seem to change anything?

I was thinking about redistribution of one's work. It would be a lot of hassle for a simple patch.

I'm not sure I follow: If you give someone your patch, you also have to give them your patch?

edit: And, if you don't give someone your patch, you don't have to give someone your patch?

I'd much prefer to rely on a well tested HTTP library than roll my own. If I discovered bugs that the upstream maintainers refused to fix (for whatever reason) I would just fork the library and fix the bugs myself. You'd have to fix many more bugs if you rolled your own.

I don't understand your point. A normal user has very few options when it turns out there's a bug in their off-the-shelf standalone webserver, too. They can fix it themselves, work around it, or report a bug and wait for someone else to fix it. Exactly as in Go.

Are you saying everyone should write their own HTTP server from scratch?

Packages in the Go standard library are no different from user packages – they're just included in the Go distribution. If you find the need to modify anything in net/http (to fix a bug, add low-level hooks, etc), just copy it into a subfolder in your project, like so:

> cp -R $GOROOT/src/pkg/net/http ./net/http

Then simply change all "net/http" imports to "./net/http". Now you're free to carry out any changes you'd like.

P.S: Just because you can do this doesn't mean you should.

Reply on news.ycombinator.com