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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev