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
