Open Stack

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