Open Stack

Excerpts from Hayes, Graham's message of 2016-05-09 11:58:38 -0700:
> 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
> 

I love this, first a bikeshed statement: "Python is too damn slow for
DNS", and a few lines later "Perfect bikeshed topic".

There are all kinds of reasons to pick languages, but I think it would
be foolish of OpenStack to ignore the phenomenon of actual deployers
choosing Go to address OpenStack's shortcomings. Whether they're right,
I'm not sure, but I do know that the community wants to invest in things
that aren't Python, and so, that fact should at least be considered
fully before making any long term decisions.