Open Stack

-----Original Message-----
From: Dmitry Tantsur <dtantsur at redhat.com>
Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Date: May 16, 2016 at 09:55:27
To: openstack-dev at lists.openstack.org <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [tc] supporting Go

> 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.

Have you written a lot of Rust? Rust handles the memory management for you as well. Certainly, you can determine the lifetime of something and tell the compiler how the underlying memory is shared, but Rust is far better than C in so much as you should never be able to write code that doubly frees the same memory unless you're explicitly using the unsafe features of the language that are infrequently needed.

I'm with Flavio about preferring Rust personally, but I'm not a member of either of these teams and I understand the fact that most of the code is already written and has been shown to drastically improve performance in exactly the places where it's needed. With all of that in mind, I'm in favor of just agreeing already that Go is okay. I understand the concern that this will increase cognitive load on some developers and *might* have effects on our larger community but our community can only grow so long as our software is usable (performant) and useful (satisfies needs/requirements).

--  
Ian Cordasco