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

[Martin Kletzander]

On Tue, Nov 28, 2017 at 10:47:33AM +0000, Nir Soffer wrote:
>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
>

Sorry, I meant s/initialized/non-nil/

>
>> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20171128/f218a8a1/attachment-0001.sig>