<i>Go also shares some attributes with Erlang; in particular, its “goroutine” construct makes writing concurrent software much easier than managing threads by hand,</i><p>That's a lot of handwaving. The overlap is that both Go and Erlang have lightweight threads. But Erlang uses the (fairly) different actor model, which usages messaging between actors, supervision trees to control and monitor the life cycles of actors, remote actors, etc. Go has lightweight threads and channels to communicate between threads. Go (concurrency) shares very little with Erlang.<p>It's also funny that they move on to claim that Go has better concurrency support than Java, when in fact, you can use real Erlang-like actor networks in Java by adding one dependency to your Maven file. Akka actors are lightweight concurrent entities, since you can easily create hundreds of thousands or even millions of actors.<p>That said, it's interesting to see one API for multiple clouds.<p>[1] <a href="http://akka.io/" rel="nofollow">http://akka.io/</a>
I think it's a noble effort, but I'd be strongly concerned with the ease of use/digestion/maintainability of something that strives to cover most major cloud APIs. This stuff moves <i>fast</i>, and I can't imagine having to try to keep up with multiple larger platforms.<p>While we were getting Pathwright launched, we contributed a whole lot to boto, which is primarily (but not exclusively) catered to AWS. It grew Eucalyptus (not a huge jump) and Google Compute support, but they were badly documented/tested and still seem to see much less maintenance than the AWS stuff. The situation has improved slightly as Amazon has hired a few more guys to help the maintainer make boto awesome, but they're still playing catchup with the core competency (AWS). This isn't to talk badly of boto, it's more to illustrate the magnitude of the task of keeping up with even one aggressively developing vendor.<p>I worry that these "mega-cloud-libs" are the wrong approach. The OpenStack stuff will probably end up with excellent support, but the others are likely to see much less attention, documentation, maintenance, help. The neglected areas of the codebase get to be embarrassing and not up to the quality standards of the primary focus (OpenStack in this case). Perhaps they end up falling behind in API versions for some vendors, limiting their utility.<p>This is definitely not to poo-poo the effort, I think it's a really neat ideal. Personally, I'd love to see them focus on making a kick ass OpenStack Go API with top notch documentation and tests, and leave the other services to their respective communities. That alone would be noteworthy.
First there's a huge caveat to calling this multi-cloud, ie. its a library for openstack clouds only from what i gather of the src and documentation. Second, there's already a nice go library for openstack clouds that's seen multiple cloud usage (rackspace, hpcloud, openstack grizzly/folsom) in the form of <a href="http://launchpad.net/goose" rel="nofollow">http://launchpad.net/goose</a> It has significantly more coverage of available openstack services (image, compute, storage) and more realworld usage and better testing afaics.
> <i>by Rob Pike and Ken Thompson</i><p>Why does everyone always forget Robert Griesemer? He might not be as involved with the public as Rob Pike, but he's the guy that made gofmt and godoc (and I'm pretty sure he's also at least partially to thank for the language being specified in such a way that it is "gofmt"-able in the first place, considering he maintains the spec). That alone counts as a pretty big positive influence on the language.
Interesting. Browsing the code it looks like they are using closures[1] in a way I haven't seen other Go code use them. Similar to the "using" keyword in .NET or the "with-" macros (with-open-file) in Common Lisp.<p>[1] <a href="https://github.com/rackspace/gophercloud/blob/master/acceptance/04-create-server.go" rel="nofollow">https://github.com/rackspace/gophercloud/blob/master/accepta...</a>