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-technologyI'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
pgpyc53lM9bBb.pgp
Description: PGP signature
__________________________________________________________________________ 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
