5 ms·
There is a way to have your cake and eat it too: rust. In rust, you have: let s = S{foo: 42, ..Default::default()}; You just got all the remaining fields
by TheDong 2y ago
There is a way to have your cake and eat it too: rust.
In rust, you have:
let s = S{foo: 42, ..Default::default()};
You just got all the remaining fields of 'S' set to "zero-ish" values, and there's no NPEs.
The way you do this is by having types opt in to it, since zero values only make sense in some contexts.
In go, the way to figure out if a type has a meaningful zero value is to read the docs. Every type has a zero value, but a lot of them just nil-pointer-exception or do something completely nonsensical if you try to use them.
In rust, at compiletime you can know if something implements default or not, and so you can know if there's a sensible zero value, and you can construct it.
Go doesn't give you your cake, it gives you doc comments saying "the zero value is safe to use" and "the zero value will cause unspecified behavior, please don't do it", which is clearly not _better_.
- the_gipsy 2y agoI agree that rust, with Option and Default, is the only right choice - at least from what I've tried. Elm for example has Option but nothing like Default, so sometimes it's tedious that you have to repeat a lot of handmade defaults, or you're forced to use constructor functions everywhere. But at least the program is correct! Go is like PHP in regards to pushing errors forward. You simply cannot validate everything at every step. Decoding with invariants is the right alternative.
- delusional 2y ago> There is a way to have your cake and eat it too: rust. Suppose my cake is that I have a struct A which holds a value, that doesn't have a default value, from your library B. Suppose that at the time I want to allocate A I don't yet have the information I need to initialize B, but I also know that I won't need B before I do have that information and can initialize it. In simple terms. I want to allocate A, which requires allocating B, but I don't want to initialize B, yet. What do I do? If you answer involves Option<B> then you're asking me to to grow my struct for no gain. That is clearly not _better_.
- the_gipsy 2y agoThen you can't eat it too (or else you'll get very sick with NPEs/panics), sorry.
- whytevuhuni 2y agoMore specifically, it could result in undefined behavior, if a panic happens between the allocation and initialization (i.e., it was allocated, not initialized, panicked, and something observed the incomplete struct after the panic). Alternatively, the allocation would always have to leak on panic, or the struct would have to be deallocated without a destructor running.
- tsimionescu 2y agoDoesn't Rust have explicit support for uninitialized memory, using the borrow checker to make sure you don't access it before initializing it? Or does that just work for local variables, not members of structs?
- steveklabnik 2y agoYou can’t do the “declare before initializing” thing with structs, that’s correct.
- deleted 2y ago[deleted]
- dingnuts 2y agoWhat is with Rust evangelicals shitting up Go posts? Shut up and go away! Go talk to other Rust users about it if you love it so much! it's for different things! the things I build in Go simply do not need to be robust in the way Rust requires everything to be, and it would be much more effort to use Rust in those problem domains Is Go a more crude language? maybe! but it lets me GET SHIT DONE and in this case worse really is better. All I know is that I've spent less time over the last ten years writing Go dealing with NPEs than I have listening to Rust users complaining about them! if you love Rust so much, YOU use it then! We like Go, in threads about Go. I might like Rust too, in the same way I like my bicycle and my car, if only the cyclists would shut up about how superior their choices are