[openstack-dev] Reasoning behind my vote on the Go topic

Amrith Kumar amrith at tesora.com
Tue Jun 7 21:03:42 UTC 2016

Well put Monty. It is a tough choice and neither choice was inexpensive.


> -----Original Message-----
> From: Monty Taylor [mailto:mordred at inaugust.com]
> Sent: Tuesday, June 07, 2016 3:00 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] Reasoning behind my vote on the Go topic
> This text is in my vote, but as I'm sure there are people who do not
> read all of the gerrit comments for governance changes, I'm posting it
> here so that my thoughts are clear.
> Please know that this has actually kept me up at night. I cast my vote
> on this neither glibly or superficially. I have talked to everyone I can
> possibly think of on the topic, and at the end, the only thing I can do
> is use my judgment and vote to the best of my ability. I apologize from
> the bottom of my heart to the people I find myself in disagreement with.
> I have nothing but the utmost respect for you all.
> I vote against allowing Go as an official language of OpenStack.
> "The needs of the many outweigh the needs of the few, or the one"
> I'm super unhappy about both possible votes here.
> I think go is a wonderful language. I think hummingbird is a well
> considered solution to a particular problem. I think that lack of
> flexibility is broadly speaking not a problem we have in OpenStack
> currently. I'm more worried about community cohesion in a post-Big Tent
> world than I am about specific optimization.
> I do not think that adding Go as a language to OpenStack today is enough
> of a win to justify the cost, so I don't like accepting it.
> I do not think that this should preclude serious thought about
> OpenStack's technology underpinnings, so I don't like rejecting it.
> "only a great fool would reach for what he was given..."
> I think that one of OpenStack's biggest and most loudly spoken about
> problems is too many per-project solutions and not enough holistic
> solutions. Because of that, and the six years of experience we have
> seeing where that gets us, I do not think that adding Go into the mix
> and "seeing what happens" is going to cause anything other than chaos.
> If we want to add Go, or any other language, into the mix for server
> projects, I think it should be done with the intent that we are going to
> do it because it's a markedly better choice across the board, that we
> are going to rewrite literally everything, and I believe that we should
> consider the cost associated with retraining 2000 developers as part of
> considering that. Before you think that that's me throwing the baby out
> with the bathwater...
> In a previous comment, Deklan says:
> "If Go was accepted as an officially supported language in the OpenStack
> community, I'd be the first to start to rewrite as much code as possible
> in Go."
> That is, in fact, EXACTLY the concern. That rather than making progress
> on OpenStack, we'll spend the next 4 years bikeshedding broadly about
> which bits, if any, should be rewritten in Go. It took Juju YEARS to
> rewrite from Python to Go and to hit feature parity. The size of that
> codebase was much smaller and they even had a BDFL (which people keep
> telling us makes things go quicker)
> It could be argued that we could exercise consideration about which
> things get rewritten in Go so as to avoid that, but I'm pretty sure that
> would just mean that the only conversation the TC would have for the
> next two years would be "should X be in Go or Python" - and we'd have
> strong proponents from each project on each side of the argument.
> David Goetz says "you aren’t doing the community any favors by deciding
> for them how they do their jobs". I get that, and can respect that point
> of view. However, for the most part, the negative feedback we get as
> members of the TC is actually that we're too lax, not that we're too
> strict.
> I know that it's a popular sentiment with some folks to say "let devs
> use whatever tool they want to." However, that has never been our
> approach with OpenStack. It has been suggested multiple times and
> aligning on limited chosen tech has always been the thing we've chosen.
> I tend to align in my personal thinking more with Dan McKinley in:
> http://mcfunley.com/choose-boring-technology
> I have effectively been arguing his point for as long as I've been
> involved in OpenStack governance - although probably not as well as he
> does. I don't see any reason to reverse myself now.
> I'd rather see us focus energy on Python3, asyncio and its pluggable
> event loops. The work in:
> http://magic.io/blog/uvloop-blazing-fast-python-networking/
> is a great indication in an actual apples-to-apples comparison of what
> can be accomplished in python doing IO-bound activities by using modern
> Python techniques. I think that comparing python2+eventlet to a fresh
> rewrite in Go isn't 100% of the story. A TON of work has gone in to
> Python that we're not taking advantage of because we're still supporting
> Python2. So what I've love to see in the realm of comparative
> experimentation is to see if the existing Python we already have can be
> leveraged as we adopt newer and more modern things.
> In summary, while I think that Go is a lovely language and the people
> who work on it are lovely people, while I'm sure that hummingbird is
> beneficial to the Cloud Files team in real ways and while I'm sure that
> if we were starting OpenStack from scratch today the conversations about
> how to do it might be different, I put a large value on the code and the
> community we've built and I want any decisions that we make about things
> as large as this to take the code, the people, the process and the
> results into account.
> That said, this is a democracy. I am but one vote, and I've been both
> wrong and on the losing side of an opinion before. I've already
> upstreamed changes to Go to make doing code in git.openstack.org more
> pleasant. I think zuul-cloner needs to learn about go source code
> organization regardless of the outcome of this decision. As always, I
> will both abide by and whole-heartedly support the decision of the
> democratically elected governance body, whether it matches my current
> opinion on this extremely hard and non-straightforward question or not.
> Although I know we're all fans of hyperbole around here, I certainly
> hope that everyone else who is involved and who has voluntarily agreed
> to be a part of this organization of humans with this mode of governance
> will do the same. Democracy is easy when we all agree, the real work
> comes when we don't get our way.
> Monty
> __________________________________________________________________________
> 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

More information about the OpenStack-dev mailing list