Hacker News Reader

Comment by JulianMorrison | Hacker News Reader

What this actually means: groupcache is awesome. You just act as if the cache is full, and if it isn't, it will be. Where did the data come from? That's pluggable. And no concern of the part that just serves it up. Very subtle, very nice.

View on HN

What this actually means (2): Go standard library has reasonable performance.

This won't work so beautifully when whoever implemented all the magic bits under your business logic didn't do so to deliver reasonable performance for your use case.

Or if the underlying code is in fact wrong. This turns into the kind of code you can see from Line 242:

https://code.google.com/p/google-api-go-client/source/browse...

I'm puzzled by this comment.

We optimise the standard library for the majority cases, and putting the download server into production helped us improve Go's HTTP stack for everyone. Similarly, when other users report issues with our standard library, we fix them.

The file you linked to contains some code to accommodate a bug that existed in Go 1.0 and was fixed in 1.1. Not sure what the relevance is here though.

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.

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

What I'm about to say is a little trollish, but if you use words like, "Business logic," whatever you're writing probably doesn't need to be faster than Go. And anyway, if performance sensitive bits are your thing, cgo is probably the best FFI outside of C# that I've ever used.

Also, it's a sign of a defective language that the library guards against old environments? Really?

Business logic is the word used in the slides.

Damn! Your close reading has completely disarmed my bad attitude.

Out of curiosity, have you used Lua's FFI? I found it fairly nice, so anything better would be worth studying.

Reply on news.ycombinator.com