Open Stack

On 09/05/2016 19:39, Ben Swartzlander wrote:
> On 05/09/2016 02:15 PM, Clint Byrum wrote:
>> Excerpts from Pete Zaitcev's message of 2016-05-09 08:52:16 -0700:
>>> On Mon, 9 May 2016 09:06:02 -0400
>>> Rayson Ho <raysonlogin at gmail.com> wrote:
>>>
>>>> Since the Go toolchain is pretty self-contained, most people just follow
>>>> the official instructions to get it installed... by a one-step:
>>>>
>>>> # tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
>>>
>>> I'm pretty certain the humanity has moved on from this sort of thing.
>>> Nowadays "most people" use packaged language runtimes that come with
>>> the Linux they're running.
>>>
>>
>> Perhaps for mature languages. But go is still finding its way, and that
>> usually involves rapid changes that are needed faster than the multi-year
>> cycle Linux distributions offer.
>
> This statement right here would be the nail in the coffin of this idea
> if I were deciding. As a community we should not be building software
> based on unstable platforms and languages.
>
> I have nothing against golang in particular but I strongly believe that
> mixing 2 languages within a project is always the wrong decision, and
> doubly so if one of those languages is a niche language. The reason is
> simple: it's hard enough to find programmers who are competent in one
> language -- finding programmers who know both languages well will be
> nearly impossible. You'll end up with core reviewers who can't review
> half of the code and developers who can only fix bugs in half the code.
>
> If you want to write code in a language that's not Python, go start
> another project. Don't call it OpenStack. If it ends up being a better
> implementation than the reference OpenStack Swift implementation, it
> will win anyways and perhaps Swift will start to look more like the rest
> of the projects in OpenStack with a standardized API and multiple
> plugable implementations.
>

Sure - the Designate team could maintain 2 copies of our DNS server,
one in python as a reference, and one externally in Golang / C / C++ /
Rust / $language, which would in reality need to be used by anything
over a medium size deployment.

That seems less than ideal for our users though.

This is not a "Go seems cool - lets go try that" decision from us - we
know we have a performance problem with one of our components, and we
have come to the conclusion that Go (or something like it) is the
solution.

 From a deck about "the rise and fall of Bind 10" [0] -

   "Python is awesome, but too damn slow for DNS"

0 - 
https://ripe68.ripe.net/presentations/208-The_Decline_and_Fall_of_BIND_10.pdf

-- Graham

>
>> Also worth noting, is that go is not a "language runtime" but a compiler
>> (that happens to statically link in a runtime to the binaries it
>> produces...).
>>
>> The point here though, is that the versions of Python that OpenStack
>> has traditionally supported have been directly tied to what the Linux
>> distributions carry in their repositories (case in point, Python 2.6
>> was dropped from most things as soon as RHEL7 was available with Python
>> 2.7). With Go, there might need to be similar restrictions.
>>
>> __________________________________________________________________________
>> 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
>>
>
>
> __________________________________________________________________________
> 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
>