One reason to use c++ could be to build components that we wish to share with ceph. (Not that I know of any at this time). Also c++0x11 has improved the language. But the more I hear about it, the more interesting go sounds..
----- Original Message ----- > From: "Jeff Darcy" <jda...@redhat.com> > To: "Justin Clift" <jus...@gluster.org> > Cc: "Gluster Devel" <gluster-devel@gluster.org> > Sent: Friday, September 5, 2014 11:44:35 AM > Subject: [Gluster-devel] Languages (was Re: Proposal for GlusterD-2.0) > > > 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@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
