Thursday, April 29, 2010

Go adds JSON-RPC to core lib

Recently I started looking for a small but useful project to serve as a vehicle for learning Go. After mulling on a few ideas I decided to create a JSON-RPC library. I generally appreciate the concept of RESTful webservices, but in my opinion this technology needs a simple common RPC protocol. JSON-RPC is exactly that. I find it particularly useful in protocols for controlling Daemon's remotely.

Well... I'm glad that I hadn't gotten very far in my implementation; as of 27/04/2010 JSON-RPC has been included in the core Go packages. Great minds thing a like I guess... :)

Monday, April 26, 2010

Playing with Go Memory Synchronization

Go has its own model of process/threads/light-weight processes/coroutines, these are called goroutines. Channel communication is the main method of synchronization between goroutines. There are buffered and unbuffered channels. Both types of channels block on receive. Unbuffered channels block on send, buffered channels block on send once the buffer is full.

I've created some test code based on the sample provided in the documentation in case someone else want's to play poke black-box-style at the memory model. Channel 'events' cause memory synchronization to occur. But as the documentation describes you need to be careful with buffered channels, the synchronization occurs during receive not send. If you play around with it a bit you'll see the importance of using Locks, although you'd probably want to rely on the flexibility, safety and abstraction offered by Channels.


Labels: ,

Saturday, April 3, 2010

Go Go Gadget-Concurrency

Premature optimization may be the root of all evil, but timely optimization is often required. When optimization becomes necessary, coding in Groovy can make refactoring in Java painless. However, Java is a less than ideal "systems programming" language for a number reasons, the least not being that it wasn't designed to be such. Yet if you've ever spent significant time using a dynamically typed language such as Groovy or even a statically typed yet garbaged collected like Java, you'll find having to go back to C, or C++ to be onerous to say the least. .

Enter Go. Taken from the Go Language Design FAQ:
"Go is an attempt to combine the ease of programming of an interpreted, dynamically typed language with the efficiency and safety of a statically typed, compiled language. It also aims to be modern, with support for networked and multicore computing. Finally, it is intended to be fast: it should take at most a few seconds to build a large executable on a single computer. "

This sounds almost too good to be true, mainly because it's been a long time coming. There hasn't been much inovation- at least that which has received popular traction- in the systems programming space since C/C++. Indeed, Go looks much like C itself with some of the syntax reversed. Digging a little deeper there are number of features that a programmer used to dynamic typing would consider must have. Namely maps, foreach-like loops and minimizing the type declcaration necessary for variable instantiation.

At the same time, Go offers some impressive concurrency features: light-weight 'threads' or goroutines, segmented stacks and channels as first class objects. Go multiplexes independently executing functions. When a function blocks, such as by calling a blocking system call, the run-time automatically moves other coroutines on the same operating system thread to a different, runnable thread so they won't be blocked. Combined these features make high performance concurrent applications conceptually simple.

If you haven't already, take a look at Go.

Labels: