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

On Tue, Nov 28, 2017 at 9:44 AM Martin Kletzander <mkletzan(a)redhat.com&gt; 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-managemen... > >> > > >> > >> 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(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list