[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 Tue, Nov 28, 2017 at 10:47:33AM +0000, Nir Soffer wrote:
On Tue, Nov 28, 2017 at 9:44 AM Martin Kletzander <mkletzan 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 redhat com
https://www.redhat.com/mailman/listinfo/libvir-list

Attachment: signature.asc
Description: Digital signature


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