Forget package management for a moment; we can figure it out if we need
to. The question is "Why Go" which I've pondered for a while.
If you need to write a multithreaded app, Python's GIL makes it very
hard to do. It is one reason why I pushed for HTTPD as the Keystone
front end.
Python has long held the option to optimize to native as the way to deal
with performance sensitive segments.
The question, then, is what language are you going to use to write that
perf sensitive native code?
To date, there have been two realistic options, Straight C and C++. For
numeric algorithms, there is a large body written in Fortran that are
often pulled over for scientific operations. The rest have been largely
one-offs.
Go and Rust are interesting in that they are both native, as opposed to
runtime compiled languages like Java and Python. That makes them
candidates for writing this kind of performance code.
Rust is not there yet. I like it, but it is tricky to learn, and the
packaging and distribution is still getting in place.
Go has been more aggressively integrated into the larger community.
Probably the most notable and relevant for our world is the Kubernetes
push toward Go.
In the cosmic scheme of things, I see Go taking on C++ as the "native
but organized" language, as contrasted with C which is native but purely
procedural, and thus requires a lot more work to avoid security and
project scale issues.
So, I can see the desire to not start supporting C++, and to jump right
to Go. I think it is a reasonable language to investigate for this type
of coding, but committing to it is less obvious than Javascript was:
with Javascript, there is no alternative for dynamic web apps, and for
native, there are several.
__________________________________________________________________________
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
