Open Stack

Excerpts from John Dickinson's message of 2015-04-30 09:40:02 -0700:
> Swift is a scalable and durable storage engine for storing unstructured data. It's been proven time and time again in production in clusters all over the world.
> 
> We in the Swift developer community are constantly looking for ways to improve the codebase and deliver a better quality codebase to users everywhere. During the past year, the Rackspace Cloud Files team has been exploring the idea of reimplementing parts of Swift in Go. Yesterday, they released some of this code, called "hummingbird", for the first time. It's been proposed to a "feature/hummingbird" branch in Swift's source repo.
> 
> https://review.openstack.org/#/c/178851
> 
> I am very excited about this work being in the greater OpenStack Swift developer community. If you look at the patch above, you'll see that there are various parts of Swift reimplemented in Go. During the next six months (i.e. before Tokyo), I would like us to answer this question:
> 
> What advantages does a compiled-language object server bring, and do they outweigh the costs of using a different language?
> 
>
> Of course, there are a ton of things we need to explore on this topic, but I'm happy that we'll be doing it in the context of the open community instead of behind closed doors. We will have a fishbowl session in Vancouver on this topic. I'm looking forward to the discussion.
> 

First, great job getting this out there at such an early stage. It's not
an easy thing to decide when is right to bring something out into the
light.

I would hope we can have many discussions on the mailing list first,
as it is so broad in scope, every single developer would have interest
in it, and unless we commandeer the plenary space, we probably won't
be very comfortable stacked 6 high in a fishbowl room. ;)

Some points I'd like to see discussed here, in no particular order:

* I'd also think that we need to open this up to the operators too,
  as python was chosen to be friendly to ops as well. Go is pretty ops
  friendly too, so I don't think it would be a problem, but I think this
  needs to be shared with operators before getting too far down the
  road.

* Hummingbird claims to be an attempt to "improve performance
  dramatically". I wonder if there was any attempt to use pypy to
  achieve that with the existing code base, and if you could publicize
  the results of such an attempt. If not, I think it would be quite
  interesting to see comparisons and worthwhile to attempt a pypy vs.
  cpython vs. hummingbird comparison.

* Even if the performance is better, will the maturity be regained
  quick enough to have that matter? There are some past lessons to be
  learned here: [1]

* Go's import and build system is rather odd. Python's weird distribution
  issues are at least well known in the OpenStack community. This is
  actually the main reason I've never gravitated toward Go, as I feel
  it is trying to be magical rather than logical. I imagine there are
  others who are also nervous about that.

* +1 for compiled languages that are less-daunting than say C++, but
  still help find problems early. Anybody up for a Rust version too? ;-)

[1] http://www.joelonsoftware.com/articles/fog0000000069.html