They all use the same core set of underlying design patterns. It’s very much like Sinatra in Ruby was the progenitor of Express.js in Node and Flask in Python, and Noir in Clojure. Every language implemented the same set of patterns for doing RESTful style API definitions. So the contribution that’s interesting – or one of them anyway – is that we’ve identified a simple set of core design patterns that you can use for building applications that have some type of physical real-world component or interaction.
So we started it with Ruby with R2. Not to long thereafter we got impatient and we couldn’t wait for people to copy it and we just decided we’ll copy ourselves, so we created Cylon.js and then shortly thereafter Gobot. So the core design patterns may be the same, but the actual implementations are very much intended to be idiomatic in each of the languages that the code is implemented in. That means that there are definitely some differences in the way things work internally, where R2 uses the actor model being built on top of something called [unintelligible 00:11:22.25] Cylon.js is running on top of Node.js, so it’s using the way that Node handles blocking I/O, and then Gobot is using channels to communicate the information between different goroutines that are running to handle different interactions with hardware devices.
The implementations are very much idiomatic with regard to the implementation patterns, but the net effect is that you’re using the same application development patterns. We might think of it as a sort of software factory for building hardware-oriented applications. It’s like [unintelligible 00:12:03.22] hardware-oriented applications. But the communities are a lot different.
[00:12:10.08] The Ruby community sort of stalled a little, because a lot of Rubyist these days are more interested in building web applications than anything else, and also the implementations of the runtime, the things that we needed to do as far as concurrency was concerned, really we could do them best with jRuby or with Rubinius and not with the main line Ruby itself.
With Node, we can take advantage of the way that Node handles blocking I/O, but we’re also limited by the way that Node handles blocking I/O. Node is a hack. It’s a useful hack, because most of the time the applications you’re writing, your problem in life is blocking I/O. If you’re writing web servers, your problem in life is blocking I/O. The same way as if you’re writing applications that communicate with hardware sensors, your problem is blocking I/O again; this is a different I/O, but it’s the same problem. The way that Go handles these things is so elegant and so concurrent…
I did a talk a couple of weeks ago at FOSDEM in Brussels, which is an amazing conference, by the way… It’s completely community-organized, so it’s sort of a controlled chaos of a delightful kind. There was a fantastic community room for Go. Francesc Campoy was there and did a really great talk about the state of Go 1.8. And a few other talks… I gave a talk…
I’m really excited about the prospects for Go’s total domination of the internet of things and robotic development world, and here’s why. The first one is Go’s performance – Golang’s team with 1.8, the fact that the garbage collection’s worst stop the world time is now one hundred microseconds, with a more typical average being ten microseconds — microseconds, not milliseconds. This is the kind of real-time programming capability that we need for hardware-oriented applications that are flying drones around and doing aerial acrobatics and whatever else.
The second is concurrency – the Go programmer embraces the concurrency model of Go and is able to benefit from it enormously. The fact that Go can take advantage of all the cores on the multi-core machine and many of the new [unintelligible 00:14:45.07] connected device platforms, R multi-core processors – particularly the ones from Intel, but also ones from ARM – and given how difficult it is to write multi-threaded code in C++… I mean, I’ve written C++ code for years, but [unintelligible 00:15:03.04]
When you look at the amount of effort it takes to do that in other languages, even C++ with all the different dynamically-linked libs, the fact that things are statically linked in Golang – this is really the triumvirate of core capabilities you need to do device-oriented programming. So if the Go team themselves didn’t realize how great it was for this, well we, their audience, do.