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