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@xxxxxxxxxx> 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
