[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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.  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

Attachment: signature.asc
Description: Digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]