[libvirt] Redesigning Libvirt: Adopting use of a safe language

Nir Soffer nirsof at gmail.com
Tue Nov 28 10:47:33 UTC 2017


On Tue, Nov 28, 2017 at 9:44 AM Martin Kletzander <mkletzan at redhat.com>
wrote:

> On Mon, Nov 20, 2017 at 04:57:56PM +0000, Daniel P. Berrange wrote:
> >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-management-in-rust/
> >> >
> >>
> >> 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.
> >
>
> Just a quick note on what I've found out after I dedicated half day to go
> through the tour of go and some other tutorials.  The learning curve of Go
> is
> even less steep than I though (for some unknown reason) it is.  So that's
> in
> favor of Go.  However I haven't found out how is it possible to avoid some
> SIGSEGVs or aborts since Go doesn't have many recoverable errors.  And in
> some
> cases they are not easy to spot immediately.  Or making sure struct fields
> are
> initialized.


Struct fields are always initialized to the zero value of the type, there
is no
such thing as uninitialized memory in go.
https://golang.org/ref/spec#The_zero_value


> Since libvirt strives to go for recoverable errors, I see this as
> a downside.
>
> Anyway, that's just to update others on what I've learnt.
>
> Have a nice day,
> Martin--
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20171128/d182a915/attachment-0001.htm>


More information about the libvir-list mailing list