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

[Dan Lambright]

I could see Go used for background type jobs or test harnessing in the beginning, at the discretion of the developer. The question about garbage collection is an unknown and a good point. To me, it makes sense to get experience with Go before using it in the I/O path. Particularly as the language is new.

Apparently Go does have a "kind of" inheritance. It does *not* have virtual functions. Here is a nice blog post.

https://geekwentfreak-raviteja.rhcloud.com/blog/2014/03/06/golang-inheritance-by-embedding/

----- Original Message -----
> From: "Jeff Darcy" <jdarcy at redhat.com>
> To: "Krishnan Parthasarathi" <kparthas at redhat.com>
> Cc: "Dan Lambright" <dlambrig at redhat.com>, "Gluster Devel" <gluster-devel at gluster.org>
> Sent: Monday, September 8, 2014 8:14:07 AM
> Subject: Re: [Gluster-devel] Languages (was Re: Proposal for GlusterD-2.0)
> 
> > Two characteristics of a language (tool chain) are important to me,
> > especially
> > when you spend a good part of your time debugging failures/bugs.
> > 
> > - Analysing core files.
> > - Ability to reason about space consumption. This becomes important in
> >   the case of garbage collected languages.
> > 
> > I have written a few toy programs in Go and have been following the
> > language
> > lately. Some of its features like channels and go routines catch my
> > attention
> > as we are aspiring to build reactive and scalable services. Its lack of
> > type-inference
> > and inheritance worries me a little. But, I shouldn't be complaining when
> > our default choice has been C thus far ;)
> 
> If there's going to be complaining, now's the time.  Justin's kind of
> right that we don't want to be adding languages willy-nilly.  If there's
> something about a language which is likely to preclude its use in
> certain contexts (e.g. GC languages in the I/O path) or impair our
> long-term productivity, then that's important to realize.
> Unfortunately, the list of such drawbacks for C isn't exactly
> zero-length either.
>