Image may be NSFW.
Clik here to view.
Following on from my previous blog I was interested in taking Google Go through its paces a little further.
Image may be NSFW.
Clik here to view.
We have a service desk for our clients. To streamline things it would be nice to have an on-call roster management system. Our L3 support staff are on a rotating 7 day schedule, but we want them to be able to trade days if they have something on. We’d like the system to sms and email rostered team members the day before their shift starts to let them know. In addition to this we want to route diagnostics messages from our monitoring systems (such as Zabbix) and automatically email and sms the person on call, so they get a heads up even before the ops guys contact them.
Anyway – a good candidate project to try out Google Go. A small website, the consumption and provision of REST services, a few scheduled background tasks. You get the idea.
I mentioned in my previous blog on Go that I was quite impressed by its expressiveness. I can confirm after trying it out in anger, i’m still amazed at what the Go team have achieved. This is by far the most productive natively compiled language I’ve used. The app only took a couple of hours to write (including a learning curve) and fits in a few hundred lines of sparse code using only the standard library, including templates. And it runs in a few meg of memory. Thats a whole web app, with everything statically linked into one executable.
If the Go team provided a dynamnically linked option so the standard lib could be shared between apps running the same Go version, Go executables would, incrementally, be even thinner – your little utility apps could take no more than a few K of memory – like small Unix C based utility apps now that only link to the C standard library. Even so – these numbers (both execution and memory efficiency) could turn a Raspberry Pi into a server for some of your apps. It’s been dispiriting over the last few years to watch just how easily the higher level languages suck the life out of increasingly powerful processors. Its great to see the trend reversed significantly without losing any productivity.
Once you get the hang of the Go syntax, and the ‘Go way’ of doing things, its quite simple to pick up – way simpler than say C++. For those who want to argue C++ is not THAT complex – let me quote Tom Cargil:
“If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?”
Go doesn’t have “protected abstract virtual base pure virtual private destructors”, though you’re better off coming from the C/C++ side when learning it if you had a choice. Although pointers cannot be numerically manipulated, they still exist, and since non primitives can be passed by both value and reference (unlike java) you have to be aware of them – the old * dereference and & address-of deal. Those of you coming from dynamic languages may have some trouble initially ‘getting’ pointers as they are normally well hidden under the covers of higher level languages. Don’t want to overplay that though.
Personally, i found myself reaching a pretty good level of productivity within an hour or two of hitting the keyboard cold – just by perusing the package docs and reading the “Efffective Go” article (http://golang.org/doc/effective_go.html#maps). Compilation is, for all intents and purposes (event full clean build) instantaneous – one of my favourite features of the language! The way source code is organised and compiled is simplicity itself.
Go is a ‘by default’ safe language (I imagine casual use of the ‘unsafe’ package is highly discouraged), so don’t worry about going past array bounds and causing buffer overruns (it’s not possible). Strings are a safe primitive in their own right (forget about the char array and string manipulation disasters like strcpy in C), and the concept of slices, a more flexible concept that abstracts over arrays make all array types easier to handle in any case – you generally don’t manipulate arrays directly in Go.
Although its a new language the standard library gives you a lot out of the box. Full web client and server, rpc, common transcoding, image manipulation, html templating, concurrency primitives, logging, compression, crypto, OS support is all baked in. So a use case that would necessitate a truckload of libraries in sometyhing like java would be fullly handled by the standard library in Go. Also – because the standard lib climbs so much higher up the stack, the hassles you normally get in terms of library compatibility when using C and C++ won’t exist – you get to concentrate on your problem domain, knowing any third party libs you use will just play nicely.
The other thing i noticed is that ‘duck typing’ interfaces really does allow for highly decoupled, flexible yet safe code. In practice it works quite well, without causing an unnecessary map of spaggetti dependencies.
As a systens level language its also nice to have the deeper OS integration. Things like signals are there if you need them – though obviously be aware of cross platform issues.
I’d be interested in determining Go’s garbage collector performance. Although its immediately dismissed by many more than the 0.000001% of true hard real-time developers currently working on the flight control system of the Joint Strike Fighter, its hard to play down a garbage collector’s value in the highly parralel multi-core world we are emerging into – which is why Rob Pike put it in. Common commercial operating systems do not provide fully interruptible system calls anyway – interacting with the operating system itself will introduce uncontrollable pauses from your own code. Thats not to say multi-gigabyte heaps in Java don’t currently have unacceptable pause times on the full sweeps for a lot of scenarios. I’m hoping, since Go gives you a lot more control over object allocation compared to something like Java, it would also allow you to control how intrusive garbage collection is to a similar degree. Just how much I would like to quantify. Judicious coding may well prevent significant garbage collection. Something to look into. Anyone who has deeper experience with this please let us know.
It would be great to see a grid fabric like say Redhat’s Infinispan based JBoss Grid implemented in Go. It would be lean and fast.
IDE support is, as expected for such a young language, embryonic. I was using the IntelliJ Go plugin. It’s promising but still quite raw (and its not a prod release so no criticism on that). Syntax checking lags behind typing somewhat. And there is a bug where it can’t find the main function. Adding whitespace to the source fixes it. I found it an slight inconvenience but not a blocker. I’m sure it will rapidly improve.
Anyway – I’m sold. Like I said before – from my perspective Go has blasted a hole in the productivity/runtime performance curve of programming languages.
rudi…