> On May 4, 2015, at 5:26 AM, Flavio Percoco <fla...@redhat.com> wrote: > > 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.
Just as a point of clarity (since I've seen it mentioned a few times now in this thread and elsewhere): At the current time, we are NOT planning to rewrite everything in Go. We are exploring one specific question: "is a compiled language object server worth it?". Or restated with more words: Is there a specific part of Swift that we can make more efficient by implementing in a different language such that the benefits gained outweigh the costs of using another language? And additionally, how can we as a community explore this question in the open rather than pushing this work to be done apart from the community and behind closed doors? There's already an ecosystem out there of people who have written stuff for and around Swift (ie middleware and DiskFile implementations). One of the first questions that comes up in the "what if it's not Python" discussions is "what about WSGI middleware". That right there is one reason that, for now, there are no plans to rewrite everything in Go, and should *anything* be written in something other than Python in the master branch and in a release, it will be done only after much careful consideration. --John > >> 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 > __________________________________________________________________________ > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ 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
