On 05/10/2016 07:08 PM, Flavio Percoco wrote:
On 10/05/16 13:52 -0400, Adam Young wrote:
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.
I disagree ;)
OK, you know I am a RUSTifarian. But Packaging is a real issue in
Fedora, as the Rust compiler is not packaged yet, and thus all the
downstream.
But really I was attempting to curb my enthusiasm for Rust, as it is not
the language under discussion here.
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.
I disagree! I don't believe Go will take on C++ but for the sake of
keeping this
thread a bit sane, I won't go into details here.
This is the core of the matter: they want to build something native,
performance, and threadable. The options thus far are C or C++, and I
would expect people that got to C to continue to do so; their rationale
still holds. In the past, I would have suggested people use C++ for an
Object oriented and structured code base, but Go is a viable native
alternative unlike ones we've had in the past.
Yes, yes, Rust would also work, but they are not asking about Rust. Curb
your enthusiasm, too, Flavio!
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.
I honestly don't think the above is a good enough motivation to start
such a
huge change in the community. I mean, really, I'm not opposed to Go
and I'm less
opposed to Rust.
As I've mentioned in other replies on this thread, there's more to it
than just
the service specific needs. Infra, CI, Packagers, OPs, *community*.
Flavio
__________________________________________________________________________
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
__________________________________________________________________________
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
