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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
