[openstack-dev] [tc] supporting Go
dtantsur at redhat.com
Mon May 16 14:53:40 UTC 2016
On 05/16/2016 04:35 PM, Adam Young wrote:
> On 05/16/2016 05:23 AM, Dmitry Tantsur wrote:
>> On 05/14/2016 03:00 AM, Adam Young wrote:
>>> On 05/13/2016 08:21 PM, Dieterly, Deklan wrote:
>>>> If we allow Go, then we should also consider allowing JVM based
>>> Nope. Don't get me wrong, I've written more than my fair share of Java
>>> in my career, and I like it, and I miss automated refactoring and real
>>> threads. I have nothing against Java (I know a lot of you do).
>>> Java fills the same niche as Python. We already have one of those, and
>>> its very nice (according to John Cleese).
>> A couple of folks in this thread already stated that the primary
>> reason to switch from Python-based languages is the concurrency story.
>> JVM solves it and does it in the same manner as Go (at least that's my
>> (not advocating for JVM, just trying to understand the objection)
>>> So, what I think we are really saying here is "what is our Native
>>> extension story going to be? Is it the traditional native languages, or
>>> is it something new that has learned from them?"
>>> Go is a complement to Python to fill in the native stuff. The
>>> alternative is C or C++. Ok Flapper, or Rust.
>> C, C++, Rust, yes, I'd call them "native".
>> A language with a GC and green threads does not fall into "native"
>> category for me, rather the same as JVM.
> MOre complex than just that. But Go does not have a VM, just put a lot
> of effort into co-routines without taking context switches. Different
> than green threads.
Ok, I think we have a different notion of "native" here. For me it's
being with as little magic happening behind the scenes as possible.
> You can do userland level co-routines in C, C++ and Erlang, probably
> even Rust (even if it is not written yet, no idea). Which is different
> than putting in a code translation layer.
> We are not talking about a replacement for Python here. We are talking
> about a language to use for native optimizations when Python's
> concurrency model or other overhead gets in the way.
> In scientific computing, using a language like R or Python to then call
> into a linear algebra or messaging library is the norm for just this
> reason. Since we are going to be writing the native code here, the
> question is what language to use for it.
> We are not getting rid of python, and we are not bringing in Java. Those
> are different questions.
> The question is "How do we take performance sensitive sections in
> OpenStack and optimize to native?"
> The list of answers that map to the question here as I see it include:
> 1. We are not doing native code, stop asking.
> 2. Stick with C
> 3. C or C++ is Ok
> 4. Fortran (OK I just put this in to see if you are paying attention).
> 5. Go
> 6. Rust (Only put in to keep Flapper off my back)
Count me in here as well, though of course I have no voting rights
within this issue :)
> We have two teams asking for Go, and Flapper asking for Rust. No one
> has suggested new native code in C or C++, instead those types of
> projects seem to be kept out of OpenStack proper.
>>> This is coming from someone that has done Kernel stuff. I did C++ in
>>> both the Windows and Linux worlds. I've written inversion of control
>>> stuff in C++ template metaprogramming. I am not personally afraid of
>>> writing code in either language. But I don't want to inflict that on
>>> OpenStack. Its a question of reducing complexity, not increasing it.
>>> OpenStack Development Mailing List (not for usage questions)
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev