<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Nov 28, 2017 at 9:44 AM Martin Kletzander <<a href="mailto:mkletzan@redhat.com">mkletzan@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Nov 20, 2017 at 04:57:56PM +0000, Daniel P. Berrange wrote:<br>
>On Mon, Nov 20, 2017 at 05:36:24PM +0100, Martin Kletzander wrote:<br>
>> On Mon, Nov 20, 2017 at 03:25:33PM +0000, Daniel P. Berrange wrote:<br>
>> ><br>
>> > I shouldn't have used the word "allocation" in my paragraph above. As<br>
>> > you say, both languages have similar needs around allocation. The difference<br>
>> > I meant is around deallocation policy - in Rust, object lifetime is is a more<br>
>> > explicit decision on control of the progammer, as opposed to Go's garbage<br>
>> > collection.  From what I've read Rust approach to deallocation is much<br>
>> > closer to the C++ concept of "smart pointers", eg this<br>
>> ><br>
>> >  <a href="http://pcwalton.github.io/blog/2013/03/18/an-overview-of-memory-management-in-rust/" rel="noreferrer" target="_blank">http://pcwalton.github.io/blog/2013/03/18/an-overview-of-memory-management-in-rust/</a><br>
>> ><br>
>><br>
>> This is kind of old, that code wouldn't run with newer Rust.  I guess<br>
>> that is from far ago when it was not stabilized at all.  It is a bit<br>
>> smarter now.  The fact that you have control over when the value is<br>
>> getting freed is true, however you rarely have to think about that.<br>
>> What's more important is that the compiler prevents you from accessing<br>
>> value from multiple places or not knowing who "owns" (think of it as<br>
>> "who should take care of freeing it") the variable.  If you give the<br>
>> ownership to someone you can't access it.  The difference I see is that<br>
>> if you access it after some other part of the code is responsible for<br>
>> that variable in Rust the compiler will cut you off unless you clearly<br>
>> specify how the memory space related to the variable is supposed to be<br>
>> handled.  In Go it will just work (with potential bug) but it will not<br>
>> crash because GC will not clean it up when someone can still access it.<br>
>> Granted this is usually problem with concurrent threads/coroutines (which<br>
>> I don't know how they handle access concurrent access in Go).  Also, for<br>
>> example Rust doesn't allow you to have value accessible from multiple<br>
>> threads unless it is guarded by thread-safe reference counter and does<br>
>> not allow you to modify it unless it is guarded by Mutex, RWLock or s<br>
>> one of the Atomic types.  Again, I don't know Go that much, I'm still<br>
>> yet to delve into the deep unknowns of it, but I haven't heard about it<br>
>> providing such safety.<br>
><br>
>The example you give about Rust not permitting concurrent usage is<br>
>one of the unique features I alluded to that Go doesn't have.<br>
><br>
<br>
Just a quick note on what I've found out after I dedicated half day to go<br>
through the tour of go and some other tutorials.  The learning curve of Go is<br>
even less steep than I though (for some unknown reason) it is.  So that's in<br>
favor of Go.  However I haven't found out how is it possible to avoid some<br>
SIGSEGVs or aborts since Go doesn't have many recoverable errors.  And in some<br>
cases they are not easy to spot immediately.  Or making sure struct fields are<br>
initialized.  </blockquote><div><br></div><div>Struct fields are always initialized to the zero value of the type, there is no</div><div>such thing as uninitialized memory in go.</div><div><a href="https://golang.org/ref/spec#The_zero_value">https://golang.org/ref/spec#The_zero_value</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Since libvirt strives to go for recoverable errors, I see this as<br>
a downside.<br>
<br>
Anyway, that's just to update others on what I've learnt.<br>
<br>
Have a nice day,<br>
Martin--<br>
libvir-list mailing list<br>
<a href="mailto:libvir-list@redhat.com" target="_blank">libvir-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/libvir-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/libvir-list</a></blockquote></div></div>