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

[Jeff Darcy]

> 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.