Open Stack

On 04/30/2015 12:52 PM, Jay Pipes wrote:
> On 04/30/2015 12:40 PM, John Dickinson wrote:
>> 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?
Although I have come to like python in certain ways, here is my take on 
advantages:

1. Performance
2. Code understandability, when paired with a good IDE. Particularly 
with folks new to a code base. With static typing:
     a) You can hover over any variable and know its type (and value 
when in the debugger)
     b) You can find definitions and references discriminated using real 
name scopes, not getting false hits for different variables with the 
same name
     c) You can examine static call graphs at any point in the code
     d) The IDE can do refactoring for you without worrying about 
variables names that are the same even though they are in different scopes
     e) check the features of any real modern IDE that uses static 
typing and type inference to understand the code

This sort of question has spawned many religious wars of course. 
Statically typed languages like Java can be very clunky to use with a 
lot of boilerplate code to write. It is easier to prototype things using 
a language like Python because you do not have to determine type 
structure up front. This is a double-edged sword IMO, when you are not 
prototyping.
>>
>> 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.
>
> Awesome discussion topic. I've long argued that OpenStack should be 
> the API, not the implementation, to allow for experimentation in other 
> languages such as Golang.
I have always thought there were valid arguments on both sides for the 
API vs. implementation debate, but I don't think it is necessary to 
resolve that to proceed in such a direction. Seems this is more about 
the current OpenStack position that all implementations must be written 
in Python. There would be nothing (other than vociferous objections from 
some folks :-) ) to stop us from saying that OpenStack is an 
implementation andnot an API, but not all OpenStack project 
implementations are required to use Python.

  -David


>
> Kudos to the Rackspace Cloud Files team for this effort. I'll 
> definitely dig into the code.


>
> Best,
> -jay
>
> __________________________________________________________________________ 
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev