Open Stack

On 05/18/2016 06:42 PM, Eric Larson wrote:
>
> Dmitry Tantsur writes:
>
>> This is pretty subjective, I would say. I personally don't feel Go
>> (especially its approach to error handling) any natural (at least no
>> more than Rust or Scala, for example). If familiarity for Python
>> developers is an argument here, mastering Cython or making OpenStack
>> run on PyPy must be much easier for a random Python developer out
>> there to seriously bump the performance. And it would not require
>> introducing a completely new language to the picture.
>
> In one sense you are correct. It is easier for a Pythonista to pick up
> Cython and use that for performance specific areas of code. At the
> same time, I'd argue that OpenStack as a community is not the same as
> Python at large. There are packaging requirements and cross project
> standards that also come into play, not to mention operators that end
> up bearing the brunt of those decisions. For example, Debian will
> likely not package a PyPy only version of Designate along with all its
> requirements. Similarly, while 50% of operators use packaged
> versioned, that means 50% work from source control to build, test, and
> release OpenStack projects.
>
> You are correct that my position is subjective, but it is based on my
> experiences trying to operate and deploy OpenStack in addition to
> writing code. The draw of Go, in my experience, has been easily
> deploying a single binary I've been able to build and test
> consistently. The target system has doesn't require Go installed at
> all and it works on old distros. And it has been much faster.
True as long as your Kernel is new enough.

There are some issues with Go on older kernels, so you can only go so
far back.

For a product I'm working on (outside of OpenStack) I chose Go for an
updater so we could move forward against Python3 (our Python2-based
updater wasn't portable to Python-3, and no hope of making it so).
I had kept it simple, but after I finished discovered Go didn't
officially support CentOS/RHEL5 due to kernel issues - example
https://github.com/golang/go/issues/8445 (closed as "unfortunate"), see
also http://dave.cheney.net/2013/06/18/how-to-install-go-1-1-on-centos-5
which *might* help get things working, but is not guaranteed.

That said, my CentOS/RHEL binary was built on CentOS6, it ran on CentOS5
but I also didn't do anything very spectacular - just shell calls and an
IPC for the daemon, all very simple and not timing related. Something
more complex, like what has been discussed in this thread, will likely
run into a lot more issues.

$0.02

Ben