While the proposal for Glusterd-2.0 is doing its rounds in the devel/users 
lists, let me find out how the Go toolchain fares in debugging a live 
application and a core file, with a dash of go routines and channels for good 
effect :-) Shouldn't take long. I will share my experience and lets take this 
discussion from there. Does that make sense?

~KP

----- Original Message -----
> > 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.
> 
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel

Reply via email to