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

[Dan Lambright]

One reason to use c++ could be to build components that we wish to share with ceph. (Not that I know of any at this time). Also c++0x11 has improved the language.
But the more I hear about it, the more interesting go sounds..

----- Original Message -----
> From: "Jeff Darcy" <jdarcy at redhat.com>
> To: "Justin Clift" <justin at gluster.org>
> Cc: "Gluster Devel" <gluster-devel at gluster.org>
> Sent: Friday, September 5, 2014 11:44:35 AM
> Subject: [Gluster-devel] Languages (was Re: Proposal for GlusterD-2.0)
> 
> > 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
>