Hello World in Go -- A Memcached Server

darcs is a fine revision control system. I used to use it quite a bit. The biggest problem I ever had with darcs, in practice, was not having ghc available when I'd do an OS upgrade and thus having no ability to access my repositories.

I am a pretty huge fan of git, though (obviously) so all of my new projects and many of my older ones show up on github.

Otherwise, perhaps I'd be posting this source to http://patch-tag.com/ instead. :)

Yes, goroutines are that lightweight. Rob Pike's introductory tech talk has a demo where he runs a program w/ 100,000 communicating goroutines in 1.5 seconds on a Mac laptop. See the slides at http://golang.org/doc/go_talk-20091030.pdf, page 34.

You have to be careful how you use them. Many green-threaded runtimes convert blocking I/O to non-blocking, but it appears that Go does not. If you have N goroutines blocked on I/O, it looks like Go will use N+1 pthreads to support them; thus a goroutine-per-connection model with blocking I/O is basically the same as the old thread-per-connection model (as used by Varnish or the Apache thread MPM).

This stuff isn't entirely clear to me, so maybe someone from Go land can clarify.

Yea that's probably an artifact of a C code. The correct way to handle this in go ( i think, i'm a beginner like everyone else ) is to pass around a request struct that contains an error channel and have the main connection handling gorutine select on this.

That's at least for bigger picture errors. On the method level you should use multiple return values to indicate erros (usually as last return value).

So r, err = write(y) { if (err!=nil) { request.errors <- err; return } }

I commented on that here: http://dustin.github.com/2009/11/12/gomemcached.html#comment...

Basically, it's about allowing me to express my sequence of writes without wrapping each one in an if block.

I could have also done something like

    return write(x) && write(y) [...]

or

    return write(x, y, ...)

but all I really want is to stop writing when a write fails and have the goroutine exit.

I've seen a couple people suggest using a channel for this. Containing the write within an object of sorts to contain that boolean would do roughly the same thing. I'd still need to somehow unwind the stack quickly to even know that that channel has something waiting on it.

Exactly my thoughts too. That would be an ideal server side programming tool. E.g. imagine a webserver written in Go with long polls, and the applications on it in GoScript. Or an XMPP (Wave) server. Or a distributed Map/Reduce engine.