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 <raysonlo...@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. __________________________________________________________________________ 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
