Editor's Note: This post was originally written by Ryan Betts at the VoltDB blog.

A while ago I published my Go VoltDB driver to github (https://github.com/rbetts/voltdbgo).  I wrote the driver for three reasons: to learn and write a little go; to be able to test and script against VoltDB using go; and to experiment with some different VoltDB client patterns.

We, and the community, have written several production quality drivers for VoltDB (available at http://community.voltdb.com/downloads). The go driver, however, has not been tested for production use.

With caveats complete, what's up with voltdbgo?

Firstly, it only supports synchronous clients. VoltDB 3.0 has greatly improved response latency for synchronous interactions and the go driver uses that to simplify interacting with the database.

Secondly, it uses go's reflection functionality to convert result set rows into typed structs. This makes working with result data much simpler - but has a serious side-effect; it makes testing values for SQL NULL difficult. The driver doesn't yet accommodate SQL NULL responses. I've played with different ways of handling SQL NULL but haven't settled on an API yet. Mostly, though, I'm looking forward to using the client in combination with some of the new JSON handling that is also appearing in VoltDB 3.0 where SQL NULL matters less in practice.

Thirdly, I wanted a client that minimizes boilerplate and allows succinct programs. The smallest viable client is:

func main() {
    volt, _ := voltdb.NewConnection("username", "", “localhost:21212")
    response, _ := volt.Call("@AdHoc", "select * from store order by
Key limit 3;");
    type Row struct {
        Key string
        Value string
    }
    var row Row
    for response.Table(0).HasNext() {
        response.Table(0).Next(&row)
        fmt.Printf("Row: %v %v\n", row.Key, row.Value)
    }
}

Performance?  The driver performs similarly to our Java client running synchronously. Slightly slower - but on the same order of magnitude. The biggest performance wins by far, when profiling, were found by realizing that net.TCPConn isn't doing buffered io. Word to the wise.

The language documentation is pretty sparse on that detail (though it seems more obvious in retrospect). It's also more than sparse on clarifying what errors can be returned from io. The loosely typed and poorly defined error returns from the standard library are annoying in general - and more annoying the more I use them.

Still, go is currently my favorite scripting language - and now I can use it with my favorite database.  Give it a try - send me pull requests. Let me know if you use the driver to build something interesting.