10:57 a.m.
On Mon, Nov 20, 2017 at 05:36:24PM +0100, Martin Kletzander wrote:
On Mon, Nov 20, 2017 at 03:25:33PM +0000, Daniel P. Berrange wrote:
>
> I shouldn't have used the word "allocation" in my paragraph above. As
> you say, both languages have similar needs around allocation. The difference
> I meant is around deallocation policy - in Rust, object lifetime is is a more
> explicit decision on control of the progammer, as opposed to Go's garbage
> collection. From what I've read Rust approach to deallocation is much
> closer to the C++ concept of "smart pointers", eg this
>
>
http://pcwalton.github.io/blog/2013/03/18/an-overview-of-memory-managemen...
>
This is kind of old, that code wouldn't run with newer Rust. I guess
that is from far ago when it was not stabilized at all. It is a bit
smarter now. The fact that you have control over when the value is
getting freed is true, however you rarely have to think about that.
What's more important is that the compiler prevents you from accessing
value from multiple places or not knowing who "owns" (think of it as
"who should take care of freeing it") the variable. If you give the
ownership to someone you can't access it. The difference I see is that
if you access it after some other part of the code is responsible for
that variable in Rust the compiler will cut you off unless you clearly
specify how the memory space related to the variable is supposed to be
handled. In Go it will just work (with potential bug) but it will not
crash because GC will not clean it up when someone can still access it.
Granted this is usually problem with concurrent threads/coroutines (which
I don't know how they handle access concurrent access in Go). Also, for
example Rust doesn't allow you to have value accessible from multiple
threads unless it is guarded by thread-safe reference counter and does
not allow you to modify it unless it is guarded by Mutex, RWLock or s
one of the Atomic types. Again, I don't know Go that much, I'm still
yet to delve into the deep unknowns of it, but I haven't heard about it
providing such safety.
The example you give about Rust not permitting concurrent usage is
one of the unique features I alluded to that Go doesn't have.
> On the choice of language, I will say C is a turn off to many
people
> as it is (not unreasonably) viewed as archaic, hard to learn and
> difficult to write good code in.
>
I would say this highly depends on what area you are coming from. In
the cloud world it would be viewed way differently than in the
dark^Wlow-level side of things. I don't want to compare libvirt to the
kernel for example, but I haven't heard about C being a turn-off there.
I'm wary of using the kernel as an anology for anything, because it
is special in oh so many ways from "regular" projects...
The closest comparison is K8s -> Docker, and there I do see more
engagement from Kubernetes devs down into Docker code than I ever
saw from OpenStack dev down into libvirt code. There's only so
far you can usefully take these comparisons though.
> When I worked in OpenStack it was a constant battle to get
people to
> consider enhancements to libvirt instead of reinventing it in Python.
> It was a hard sell because most python dev just didn't want to use C
> at all because it has a high curve to contributors, even if libvirt
> as a community is welcoming. As a result OpenStack pretty much reinvented
I'm sorry, but I think only handful of us (yeah, I think and hope I
could count myself amoungst that group) are welcoming. But it's
actually where I see one of the big turn-offs.
Perhaps "welcoming" was overstating things - perhaps more "not
aggressively
hostile" would be a better way of saying it.
> > 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.
>
> Many C libs we depend on have been around along time so are more
> mature, but are also more conservative in accepting changes,
> especially if they touch API. On balance I don't think there would
> be a big difference either way in this area.
>
... OK, I hope so and if you say so I will blindly believe that ;)
Mostly I'm basing this off what I see with Docker and Kubernetes.
They both relying on a huge number of 3rd party Go modules, and
their needs & scale at least on a par with libvirts. IOW, if it
is good enough for them, its a sign it would be good enough for
us.
> > 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?
>
> Yes, all the Go code is statically linked - only C libs are dyn
> loaded. This doesn't have any impact on runtime, because even if
> the binary was 100's of MB in size, the kernel is only ever going
> to page in sections of that file which are actually executed.
>
But the code that is used by each binary will be present as many times
as that binary is running since it is not dynamically loaded, right?
The memory mapping associated with /usr/bin/foo is still shared across
all instances of 'foo' that are executing.
If you have /usr/bin/foo and /usr/bin/bar though, which both static
linked to 'wizz', then you would get two copies of 'wizz' in memory
though.
> The main impact is that if a dependancy gets an update (eg for
> a security fix) all downstream apps need rebuilding.
Well, that sucks, but it's not a deal-breaker.
NB, same as ocaml and a few other languages in Fedora too.
> > 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.
>
> This is relataed to the thing I mention above where historically
> everything was just splattered into $GOPATH. Most apps have gone
> towards the vendoring concept where every dep is self-contained
> in your local checkout.
>
I have to read up on the basics on how to do a proper first-time setup
for Go. And maybe everything will be sunshine and rainbows from that
point forward. It's just that I don't like the fact that it's
non-intuitive. Is it possible somehow to just build some code without
actually dealing with bunch of dependencies and all the setup? To give
an example, is there a way to differentiate the compiler from the
dependency handling and build processes? Like gcc and
autoconf/automake/make or rustc and cargo?
The compiler binary 'go' expects all the deps to have been pulled
down locally. It will search for them in either GOPATH (the traditional
location), or local vendor/ dir (the modern location), searching
vendor/ first. The process of actually getting those deps installed
is handled by a separate tool. On my most recent code I used a tool
called 'glide', but Go is in process of unifying on a tool called
"dep".
You still need to normally checkout in $GOPATH/src/$REPOURL
eg when checking out
https://github.com/dicot-project/dicot-api
it would go into
$GOPATH/src/github.com/dicot-project/dicot-api
It would be possible to avoid this, if I made the makefile auto-populate
a $GOPATH with symlinnks, but I've not bothered to try that, as the use
of $GOPATH layout doesn't really bother me now that the 3rd party deps
are isolated into the vendor/ dir.
> > 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_ ;)
>
> Either Rust or Go would be a step forward over staying exclusively
> with C IMHO, so at least we agree that there are potential benefits
> to either :-)
>
Yeah. Good luck with evaluating the responses. I hope we won't need to
change our Code of Conduct or even resort to voting...
I think we're a way off actually getting to the point of decision making.
I would view refactoring of libvirtd into modular deamons as the more
pressing problem to tackle. Language choice is a more long term thing
to consider. Realistically it would need a real world proof of concept
illustrating the usage of $LANG in combination with C, with our codebase,
to be able to properly understand what it would look like for libvirts
POV.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|