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

[Dan Lambright]

Digging deeper into Go, I see there is a fascinating discussion in the language communities comparing Go with C++.

Go has no..
- classes (no inheritance), though it has interfaces (sets of methods) which remind me of things like gluster's struct xlator_fops {}
- polymorphism 
- pointer arithmetic
- generic programming
- etc. 

Here is a comparison of C++ with Go from Rob Pike himself (a Go author). 

http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html 

And here are a few counter arguments.

http://lambda-the-ultimate.org/node/4554

Preference for Go seems to come down to how deeply you prefer the C++ object oriented way of doing things (as Pike calls it, the "type-centric" focus on classes). If thats your cup of tea, you may find Go a letdown or step backwards. Pike implies that coders invest a lot of time to master those techniques and are reluctant to ditch those skills.

But if you are a C or python programmer, you may see Go as a way to have your cake (modern stripped down language with lists, maps, packages, interfaces, no #includes) and eat it too (it compiles to binary, no VM).

As gluster is not beholden in any way to legacy C++, Go seems like a great fit. I'm looking forward to giving it a spin :)

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