5:24 p.m.
On Tue, Nov 14, 2017 at 05:27:01PM +0000, Daniel P. Berrange wrote:
[...]
I don't have direct experiance in Rust, but it has the same kind
of benefits over
C as Go does, again without the downsides of languages like Python or Java. There
are some interesting unique features to Rust that can be important to some apps.
In particular it does not use garbage collection, instead the user must still do
manual memory management as you would with C/C++. This allows Rust to be used in
performance critical cases where it is unacceptable to have a garbage collector
run. Despite a requirement for manual allocation/deallocation, Rust still
provides a safe memory model. This approach of avoiding abstractions which will
introduce performance overhead is a theme of Rust. The cost of such an approach
is that development has a higher learning curve and ongoing cost in Rust, as
compared to Go.
I don't believe that the unique features of Rust, over Go, are important to the
needs of libvirt. eg while for QEMU it would be critical to not have a GC
doing asynchronous memory deallocation, this is not at all important to libvirt.
In fact precisely the opposite, libvirt would benefit much more from having GC
take care of deallocation, letting developers focus attention other areas. In
general, as from having a memory safe language, what libvirt would most benefit
from is productivity gains & ease of contribution. This is the core competancy
of Go, and why it is the right choice for usage in libvirt.
Even though I agree with you on most of the opinions of this thread, I
must engage in a discussion on this part. I started working on libvirt
because I liked the fact that it is in C and needs to work with the
low-level concepts and interfaces. I like python for rapid prototyping,
but I used to be against new, "hype" languages that were popping up here
and there. I must say, on the other hand, that I was surprised how
choice of language can influence the contributor flow (mostly incoming).
However I heard about this mostly happening in the ruby and node.js
communities. Along the way, I quickly stopped thinking about Rust and
Go as hype languages. Well, so much for my background...
I'm going to approach the elephant in the room, but I'm not the one to
defend the opinion as my understanding, as well as experience, is
limited. On the other hand, that could show you that it is not that
hard for a newbie to get the hang of it. I'm saying this because I
might get some things wrong, but I expect the wrong information to be
related mainly to Go.
So the first thing I disagreed on is that in Rust you do manual
allocations. In fact, you don't. Or, depending on the point of view,
you do less or the same amount of manual allocation than in Go. What is
the clear win for Rust it the concept of ownership and it's related to
the allocation mentioned before.
I am standing strongly behind the opinion that the learning curve of
Rust is definitely worth it. And coming from the C world, it is easy to
understand. To me, it is very easy to explain that concept to great
detail to someone who has background in libvirt. And the big benefit
(and still a huge opportunity for improvement WRT optimizations) is that
the compiler must know about it and so it is resolved compile-time.
Dereferencing or destructors are run at the end of their scope,
automatically. You can nicely see that when realizing that Rust doesn't
need any `defer` as Go has.
Sure, Rust doesn't have green threads implementation, however there
should be support for that in some library. I used vague wording due to
the fact that I haven't yet found it, however it is mentioned in
official docs. Apparently it was removed from the standard library due
to requirements on runtime size.
Rust's slogan (or one of them?) is "fearless concurrency". It builds
upon the ideas from Go, however, having more information it can work
with it better. It could help us considering how many problems we have
with reference counting and similar.
So much for defending Rust. Long story short, I think we could benefit
a tiny (well, IMHO not really tiny) bit more if we go that route
instead. Now for some more opinions I have. Stay with me.
Not considering the Linux kernel, which has their own address sanitizer,
randomizer and god-knows-whatifier, there is still plethora or projects
that are successful in C and I don't see how they would need to adapt or
die. I know we have bunch of stuff that needs to be fixed and the
current approach doesn't make it easy. I, myself, thought about
proposing new version of libvirt, which would be a rewrite of the
current one. Thanks to that I have some reasons why I didn't do that.
One of the things is that the kinks we have can be ironed out in C as
well. It might be easier in other languages, but it is harder when you
have to switch to one. We have bunch of code dealing with backwards
compatibility. And I argue that this is something that causes issues on
its own. What's even worse, IMHO, is that we are so much feature-driven
that there is no time for any ironing. I see too much potential for
refactoring in various parts of libvirt that will never see the lights
of day because we need X to be implemented. And contributors sending
feature requests that they fail to maintain later don't help much with
that. Maybe we could fix this by saying the next Y releases will just
be bugfix releases. Maybe we could help bringing new contributors by
devoting some of our time to do an actual change that will make them
want to help us more. I know some of you will be sick and tired hearing
about Rust once more, but have you heard about how much their community
is inclusion-oriented? I guess what I'm trying to say is that there are
other (and maybe less disruptive) ways to handle the current problems we
are facing.
And then there are the "issues" with Go (and unfortunately some with
Rust as well :'( ).
Lot of the code for libraries is written with permissive licences, but
if there is some that is LGPL-incompatible we can't use them. And in
ecosystems such as Rust and Go there are fewer alternatives, so we might
not find one that we'll be able to use. If that happens, there goes
bunch of our time. Like nothing.
How do we deal with problems/bugs in dependence libraries? I know, all
the projects are pretty new, so they might be nicer to contributors. If
they are not, we might need to fork or rewrite the code. Bam, another
chance of losing workforce.
If I may, I will ask some things about Go that I'm not that familiar
with and I think they are pretty important.
How does Go handle updates in dependency libs? Does it automatically
pull newest version from public repositories where some unknown person
can push whatever they want? Or can they be hash- or version-bound?
The build process is that all the binaries are static, right? Or all
the go code is static and it only has dynamic dependencies on C
libraries? In such a project as libvirt, wouldn't that mean that the
processes we run will be pretty heavy-weight?
How is it with rebuilding after a small change. I know Go is good when
it comes to compilation times. That might be something that people
might like a lot. Especially those who are trying to shave off every
second of compilation. However if you cannot use ccache and you always
need to rebuild everything, it might increase the build-time quite a
lot, even thought indirectly.
Since there were some hateful opinions about Go, let me add my share as
well. Just so we are on the same page and I don't miss saying anything.
Not that these opinions would be as important as the ones above.
You can't have /tmp mounted with noexec option unless you have TMPDIR
set to some other directory. And sometimes not even in that case. I
guess non-issue for some distros, but bunch of people deal with that and
if seems like something that could be taken care of in Go itself and it
is just not.
You can't just clone a repo, cd into it and build it. You have to get
the dependencies in a special manner, for that you have to have GOPATH
set and based on that you have to have your directories setup similarly
to what Go expects, then you need GOBIN if you want to build something
and other stuff that's just not nice and doesn't make much sense. At
least for newcomers. Simply the fact that it seems to me like Go is
trying to go against the philosophy of "Do one thing and do it well". I
know everyone is about having the build described in the same language
as the project, but what comes out of it is not something I prefer.
I'm not against using another language to make some stuff better. I
guess it is kind of visible from the mail that I like Rust, but I'm not
against other languages as well. I just want this to be full on
discussion and I want my opinion to be expressed. Thanks for
_listening_ ;)
Have a nice day,
Martin