[openstack-dev] [tc] supporting Go

Clint Byrum clint at fewbar.com
Mon May 9 19:51:08 UTC 2016


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.



More information about the OpenStack-dev mailing list