Excerpts from Tim Simmons's message of 2016-05-09 18:29:30 +0000: > > The point here though, is that the versions of Python that OpenStack > > has traditionally supported have been directly tied to what the Linux > > distributions carry in their repositories (case in point, Python 2.6 > > was dropped from most things as soon as RHEL7 was available with Python > > 2.7). With Go, there might need to be similar restrictions. > > I'm not sure about this, backwards compatibility in Go (at least in the last > year) has been good > for me. > > But because like you say, you get a statically-linked binary, you don't need > to > worry about some version of anything the distro is packaging because your > binary > will run anywhere. > > If you're looking to compile the code from scratch, it's intentionally simple > to install the > compiler, and there isn't any reason that you couldn't install multiple > versions simply.
I think the idea is to avoid having a compile-time dependency on a version that isn't part of what the distros package (and therefore have available for building packages of the software we've written). We push them hard on library dependencies, but try to be flexible with language tools. That's why we waited to drop python 2.6 support until everyone had at least 2.7, for example. Doug > > >> I think you'll find that being able to embed a higher performance language > >> inside python will be much > >> easier to do for optimizing a function or two rather then deal with having > >> a separate server have to be created, > >> authentication be added between the two, and marshalling/unmarshalling the > >> data to and from it to optimize one little piece. > >> Last I heard, you couldn't just embed go in python. C/C++ is pretty easy > >> to do. > >> Maybe I'm wrong and its possible to embed go now. Someone, please chime in > >> if you know of a good way. > > There isn't a good way to embed Go (as far as I know), but I'd argue that for > a relatively isolated use case (like Graham described > of ours), it's better to just do the thing in Go than coerce C into Python. > It'd introduce less risk and complexity than using Cython, imho. > But I guess if you know C and not Go, that could be arguable. > > Tim Simmons > ________________________________________ > From: Clint Byrum <cl...@fewbar.com> > Sent: Monday, May 9, 2016 1:15 PM > To: openstack-dev > Subject: Re: [openstack-dev] [tc] supporting Go > > Excerpts from Pete Zaitcev's message of 2016-05-09 08:52:16 -0700: > > On Mon, 9 May 2016 09:06:02 -0400 > > Rayson Ho <raysonlo...@gmail.com> wrote: > > > > > Since the Go toolchain is pretty self-contained, most people just follow > > > the official instructions to get it installed... by a one-step: > > > > > > # tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz > > > > I'm pretty certain the humanity has moved on from this sort of thing. > > Nowadays "most people" use packaged language runtimes that come with > > the Linux they're running. > > > > Perhaps for mature languages. But go is still finding its way, and that > usually involves rapid changes that are needed faster than the multi-year > cycle Linux distributions offer. > > Also worth noting, is that go is not a "language runtime" but a compiler > (that happens to statically link in a runtime to the binaries it > produces...). > > The point here though, is that the versions of Python that OpenStack > has traditionally supported have been directly tied to what the Linux > distributions carry in their repositories (case in point, Python 2.6 > was dropped from most things as soon as RHEL7 was available with Python > 2.7). With Go, there might need to be similar restrictions. > __________________________________________________________________________ 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
