On 09/08/2014 10:29 PM, Krishnan Parthasarathi wrote:
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?
One more thing to explore is Go is not free from data
races.(http://dave.cheney.net/2014/06/27/ice-cream-makers-and-data-races)
--
regards
Aravinda
http://aravindavk.in
~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@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
