Open Stack

On 04/05/15 12:17 +0200, Thierry Carrez wrote:
>Monty Taylor wrote:
>> On 04/30/2015 08:06 PM, John Dickinson wrote:
>>>>> What advantages does a compiled-language object server bring,
>>>>> and do they outweigh the costs of using a different language?
>>>>>
>>>>> Of course, there are a ton of things we need to explore on this
>>>>>  topic, but I'm happy that we'll be doing it in the context of
>>>>> the open community instead of behind closed doors. We will
>>>>> have a fishbowl session in Vancouver on this topic. I'm
>>>>> looking forward to the discussion.
>>
>> I'm excited to see where this discussion goes.
>>
>> If we decide that a portion of swift being in Go (or C++ or Rust or
>> nim) is a good idea, (just as we've decided that devstack being in
>> shell and portions of horizon and tuskar being in Javascript is a good
>> idea) I'd like to caution people from thinking that must necessarily
>> mean that our general policy of "python" is dead. The stance has
>> always been "python unless there is a compelling reason otherwise". It
>> sounds like there may be a compelling reason otherwise here.
>>
>> Also:
>>
>> http://mcfunley.com/choose-boring-technology
>
>I'm pretty much with Monty on this one. There was (and still is)
>community benefits in sharing the same language and development culture.
>One of the reasons that people that worked on one OpenStack project
>continue to work on OpenStack (but on another project) is because we
>share so much (language, values, CI...) between projects.
>
>Now it's always been a trade-off -- "unless there is a compelling reason
>otherwise". JavaScript is for example already heavily used in OpenStack
>GUI development. We just need to make sure the trade-off is worth it.
>That the technical benefit is compelling enough to outweigh the
>community / network drawbacks or the fragmentation risks.

TBH, I'm a bit torn. I'm always cheering for innovation, for using the
right tool, etc, but I also agree with Monty, the linked post and some
of the arguments that have been made in this thread.

To some extent, I believe it'd be fair to say that as long as all the
other aspects are maintained by the project itself, it should be fine
for projects to do this. To be more precise, I don't think our infra
team should reply to the request of having a Go/Rust/Nim CI unless
there are enough cases that would make this worth it for them to offer
this service. This means, swift needs to run their own CI for the Go
code, provide tools for deplying it, etc.

One question that raises (naturally?) is whether Swift will end up
being completely rewritten in Go? I wouldn't discard this option.

>That said, of all the languages we could add, I think Go is one that
>makes the most sense community-wise (due to its extensive use in the
>container world).

Not going to get into language wars but the above is also arguable.
I'm not against Go itself, it's just that choosing a language to use
for a task is hardly that simple.

Cheers,
Flavio


-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150504/da97e2a7/attachment.pgp>