On 05/11/2016 09:50 PM, Eric Larson wrote:
Flavio Percoco writes:
On 11/05/16 09:47 -0500, Dean Troyer wrote:
On Tue, May 10, 2016 at 5:54 PM, Flavio Percoco <fla...@redhat.com>
wrote:
[language mixing bits were here]
The above is my main concern with this proposal. I've mentioned
this in the upstream review and I'm glad to have found it here as
well. The community impact of this change is perhaps not being
discussed enough and I believe, in the long run, it'll bite us.
Agreed, but to do nothing instead is so not what we are about. The
change from integrated/incubated to Big Tent was done to address some
issues knowing we did not have all of the answers up front and would
learn some things along the way. We did learn some things, both good
and bad.
I do believe that we can withstand the impact of a new language,
particularly when we do it intentionally and knowing where some of
the pitfalls are. Also, the specific request is coming from the
oldest of all OpenStack projects, and one that has a history of not
making big changes without _really_ good reasons. Yes it opens a
door, but it will be opened with what I believe to be a really solid
model to build upon in other parts of the OpenStack community. I
would MUCH rather do it this way then with a new Go-only project that
is joining OpenStack from scratch in more than just the
implementation language.
So, one thing that was mentioned during the last TC meeting is to
decide this in a project basis. Don't open the door entirely but let
projects sign up for this. This will give us a more contained growth
as far as projects with go-code go but it does mean we'll have to do a
technical analysis on every project willing to sign up and it kinda
goes against the principles of the big tent.
The feedback from the Horizon community has been that it's been
impossible to avoid a community split and that's what I'd like to
avoid.
I do think part of this is also due to the differences in the problem
domain of client/browser-side and server-side. I believe there is a
similar issue with <any-language> devs writing SQL, the overlap in
expertise between the two is way smaller than we all wish it was.
Exactly! This separation of domains is the reason why opening the door
for JS code was easier. The request was for browser apps that can't be
written in Python.
And for the specific Python-Golang overlap, it feels to me like more
Python devs have (at least talked about) working in Go than in other
newish languages. There are worse choices to test the waters with.
Just to stress this a bit more, I don't think the problem is the
language per se. There are certainly technical issues related to it
(packaging, CI, etc) but the main discussion is currently going around
the impact this change will have in the community and other areas. I'm
sure we can figure the technical issues out.
One thing to consider regarding the community's ability to task switch
is how Go is much easier than other languages and techniques. For
example, one common tactic people suggest when Python becomes too slow
is to rewrite the slow parts in C. In designate's case, rewriting the
dns wire protocol aspects in C could be beneficial, but it would be very
difficult as well. We would need to write an implementation that is able
to safely parse dns wire format in a reasonably thread safe fashion that
also will work well when those threads have been patched by eventlet,
all while writing C code that is compatible with Python internals.
To contrast that, the go POC was able to use a well tested go DNS
library and implement the same documented interface that was then
testable via the same functional tests. It also allowed an extremely
simple deployment and had a minimal impact for our CI systems. Finally,
as other go code has been written on our small team, getting Python
developers up to speed has been trivial. Memory management, built in
concurrency primitives, and similar language constructs have made using
Go feel natural.
This is pretty subjective, I would say. I personally don't feel Go
(especially its approach to error handling) any natural (at least no
more than Rust or Scala, for example). If familiarity for Python
developers is an argument here, mastering Cython or making OpenStack run
on PyPy must be much easier for a random Python developer out there to
seriously bump the performance. And it would not require introducing a
completely new language to the picture.
This experience is different from JavaScript because there are very
specific silos between the UI and the backend. I'd expect that, even
though JavaScript is an accepted language in OpenStack, writing a
node.js service would prevent a whole host of new complexity the project
would similarly debate. Fortunately, on a technical level, I believe we
can try Go without its requirements putting a large burden on the CI
team resources.
Eric
Flavio
dt
--
Dean Troyer dtro...@gmail.com
--
Eric Larson | eric.lar...@rackspace.com Software Developer |
Cloud DNS | OpenStack Designate Rackspace Hosting | Austin, Texas
__________________________________________________________________________
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
