Open Stack

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.

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)


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