On Wed, May 11, 2016, at 03:24 AM, Thierry Carrez wrote: > > That said I know that the Swift team spent a lot of time in the past 6 > years optimizing their Python code, so I'm not sure we can generalize > this "everything to do with the algorithms" analysis to them ? >
I agree. The swift case is clearly a not easy engineering problem and the awesome write up we got on it points out what issues they are running in to that aren't easily solved. At that point the onus is on us to either be certain there is a much easier way for them to solve the issues they are running in to without the cost to the community or to accept that another tool might be good for this job. Personally, I can completely empathize with running into a problem that requires a lot of direct OS interaction and just wanting a tool that gets out of my way for it. I might have picked a different tool, but I don't think that is the point of the conversation here :). I know we have a lot of Python gurus here though, so maybe they feel differently. Even if we're OK with part of Swift being in Go, I do still think there is a lot of value in us remaining a Python project rather than a Python+Go project. I really think Swift might be *the* exception to the rule here and we don't need to completely open ourselves up to anyone re implementing in Go as a result. Yes, some of the cost of Go will be lowered when we support a single project having Go in tree, but there are plenty of additional costs - especially for us all understanding a common language/toolset - which aren't effected much by having one component of one project be in a different language. Cheers, Greg __________________________________________________________________________ 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
