Julius Plenz – Blog

Go: First Impressions

I’ve been experimenting with the Go Programming Language for the past few days. (Thanks to Jürgen, who held two introduction sessions at work.) I have not dived very deeply into the language, but already I feel it suits me pretty well.

Go is a really clean and simple, yet powerful language. Here’s what I like so far:

I have not really fully grasped the importance of interfaces, but I guess I’ll come to that in a few days.

So far, there’s one thing I don’t like: The error checking idiom

result, err := function(...)
if err != nil {
    // handle error
}

It’s not the multi-value return… I find that much better than the usual try-catch-blocks. (Quote Rob Pike: “errors are not exceptional!”) It’s just that I’d like to check for an error, not if the error is not nothing. From a logician’s point of view it’s the same. But I believe if you could somehow write if err { ... } the code would be so much more readable. Why can’t nil be cast to the Bool type false?

Go is really easy to start with. It took me all of one hour to do a simple client-server-application than can pass a Go struct using net/rpc.

But I am not really sure yet how well Go scales. That is, how much parallelisation is actually good. I did a little coding exercise: On my system, grep is CPU-bound when the relevant files are in the disk cache. So I thought, maybe I can simply create a multithreaded grep in Go.

I have a simple version (simple as in: it emulates fgrep -IR) that uses one goroutine for every file. The workers themselves are sent over a channel (a “channel of channels”) so that the order of output files resembles the order of files checked.

However, my grep is an order of magnitude slower than the real grep. I tried using the profiler, but I haven’t gotten any meaningful results out of it. If you have a clue to that problem, please write me an e-mail!

posted 2012-10-27 tagged golang