> 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@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
