On 16 May 2016, at 8:14, Dmitry Tantsur wrote:
> On 05/16/2016 05:09 PM, Ian Cordasco wrote: >> >> >> -----Original Message----- >> From: Dmitry Tantsur <dtant...@redhat.com> >> Reply: OpenStack Development Mailing List (not for usage questions) >> <openstack-dev@lists.openstack.org> >> Date: May 16, 2016 at 09:55:27 >> To: openstack-dev@lists.openstack.org <openstack-dev@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? > > Not a lot, but definitely some. > >> 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 think we're in agreement here, not sure which bit you're arguing against :) > >> >> 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). > > This Rust discussion is a bit offtopic, I was just stating that my notion of > "nativeness" of Go is closer to one of JVM, not one of C/C++/Rust. > > I guess my main question is whether folks seriously considered > PyPy/Cython/etc. Yes. http://lists.openstack.org/pipermail/openstack-dev/2016-May/094960.html (which also references http://lists.openstack.org/pipermail/openstack-dev/2016-May/094549.html and http://lists.openstack.org/pipermail/openstack-dev/2016-May/094720.html --John
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ 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
