[Gluster-devel] Languages (was Re: Proposal for GlusterD-2.0)

[Luis Pabón]

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:

http://goo.gl/g9abOi

Hope this helps.

- Luis

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
> alternatives.
>
>   * 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
>     dependencies.
>
>   * JavaScript
>     Ubiquitous.  Common in HTTP-ish "microservice" situations, but not so
>     much in true distributed systems.
>
>   * Ruby
>     Much like JavaScript as far as we're concerned, but less ubiquitous.
>
>   * 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
> serious drawbacks are JavaScript and Go.  As popular as JS is in other
> 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
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel