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 -- 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-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 > __________________________________________________________________________ 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