[Gluster-devel] Languages (was Re: Proposal for GlusterD-2.0)
lpabon at redhat.com
Thu Sep 11 00:47:44 UTC 2014
Hi guys, I wanted to share my experiences with Go. I have been using it
for the past few months and I have to say I am very impressed. Instead
of writing a massive email I created a blog entry:
Hope this helps.
On 09/05/2014 11:44 AM, Jeff Darcy wrote:
>> Does this mean we'll need to learn Go as well as C and Python?
> As KP points out, the fact that consul is written in Go doesn't mean our
> code needs to be ... unless we need to contribute code upstream e.g. to
> add new features. Ditto for etcd also being written in Go, ZooKeeper
> being written in Java, and so on. It's probably more of an issue that
> these all require integration into our build/test environments. At
> least Go, unlike Java, doesn't require any new *run time* support.
> Python kind of sits in between - it does require runtime support, but
> it's much less resource-intensive and onerous than Java (no GC-tuning
> hell). Between that and the fact that it's almost always present
> already, it just doesn't seem to provoke the same kind of allergic
> reaction that Java does.
> However, this is as good a time as any to think about what languages
> we're going to use for the project going forward. While there are many
> good reasons for our I/O path to remain in Plain Old C (yes I'm
> deliberately avoiding the C++ issue), many of those reasons apply only
> weakly to other parts of the code - not only management code, but also
> "offline" processes like self heal and rebalancing. Some people might
> already be aware that I've used Python for the reconciliation component
> of NSR, for example, and that version is in almost every way better than
> the C version it replaces. When we need to interface with code written
> in other languages, or even interact with communities where other
> languages are spoken more fluently than C, it's pretty natural to
> consider using those languages ourselves. Let's look at some of the
> * C++
> Code is highly compatible with C, programming styles and idioms less
> so. Not prominent in most areas we care about.
> * Java
> The "old standard" for a lot of distributed systems - e.g. the
> entire Hadoop universe, Cassandra, etc. Also a great burden as
> discussed previously.
> * Go
> Definitely the "up and comer" in distributed systems, for which it
> was (partly) designed. Easy for C programmers to pick up, and also
> popular among (former?) Python folks. Light on resources and
> Ubiquitous. Common in HTTP-ish "microservice" situations, but not so
> much in true distributed systems.
> * Ruby
> * Erlang
> Functional, designed for highly reliable distributed systems,
> significant use in related areas (e.g. Riak).
> Obviously, there are many more, but issues of compatibility and talent
> availability weigh heavier for most than for Erlang (which barely made
> the list as it is despite its strengths). Of these, the ones without
> specialties, I just don't feel any positive "pull" to use it in anything
> we do. As a language it's notoriously loose about many things (e.g.
> equality comparisons) and prone to the same "callback hell" from which
> we already suffer.
> Go is an entirely different story. We're already bumping up against
> other projects that use it, and that's no surprise considering how
> strong the uptake has been among other systems programmers.
> Language-wise, goroutines might help get us out of callback hell, and it
> has other features such as channels and "defer" that might also support
> a more productive style for our own code. I know that several in the
> group are already eager to give it a try. While we shouldn't do so for
> the "cool factor" alone, for new code that's not in the I/O path the
> potential productivity benefits make it an option well worth exploring.
> Gluster-devel mailing list
> Gluster-devel at gluster.org
More information about the Gluster-devel