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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
