Open Stack

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
>>>> languages.
>>> 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
>> assumption).
>>
>> (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.

>
> http://programmers.stackexchange.com/questions/222642/are-go-langs-goroutine-pools-just-green-threads
>
>
>
> 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)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __________________________________________________________________________
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev