4 ms·

> It means that now you need to have rules in the language for definitely-initialized fields (since you can't just default-init them to null as there is no null

> It means that now you need to have rules in the language for definitely-initialized fields (since you can't just default-init them to null as there is no null). You don't need rules, you just don't allow for uninitialized fields. > Which means that you need full-fledged constructors for everything, and syntax for invoking them in all cases where they may be needed Rust doesn't have constructors. It's not needed. > - e.g. think about what should happen if you try to create an array of structs with ref fields in them. struct Ref<'a> { x: &'a i32, } fn main() { let a = 5; let array = [ Ref { x: &a }, Ref { x: &a }, ]; } No big deal. This all being said, that doesn't mean that I think zero values are a mistake in Go, exactly. They make sense with the design of the language. But I do think both sides of this have tradeoffs, and I personally prefer the tradeoffs of no nulls and zero values.

int_19h 2y ago
> you just don't allow for uninitialized fields It sounds simple, but it's the kind of thing that has very far-reaching effects across the language. If you start with this premise and then design everything else around it, things feel natural. If you take a language already designed around the notion of null values and bolt things on, either idiomatic code changes massively, or you leave enough loopholes in the type system to still let people write the stuff they have always done and that always worked (even though it's technically unsound). And yes, of course it's a tradeoff. For my own part, I also think that null values and the simplicity that comes with them in some things aren't worth the trouble that they bring. I'm also not a fan of Go, to put it mildly. But given where the language is already, and given their explicit stated design goals (which I disagree with), I can totally see why on this particular issue they went with nulls just to keep things simple that were traditionally simple.
- steveklabnik 2y ago
  > But given where the language is already, and given their explicit stated design goals I fully agree, which I tried to say at the end. All I was saying is that you don't need all of the stuff you're talking about to make this work.

int_19h 2y ago

> you just don't allow for uninitialized fields It sounds simple, but it's the kind of thing that has very far-reaching effects across the language. If you start with this premise and then design everything else around it, things feel natural. If you take a language already designed around the notion of null values and bolt things on, either idiomatic code changes massively, or you leave enough loopholes in the type system to still let people write the stuff they have always done and that always worked (even though it's technically unsound). And yes, of course it's a tradeoff. For my own part, I also think that null values and the simplicity that comes with them in some things aren't worth the trouble that they bring. I'm also not a fan of Go, to put it mildly. But given where the language is already, and given their explicit stated design goals (which I disagree with), I can totally see why on this particular issue they went with nulls just to keep things simple that were traditionally simple.

steveklabnik 2y ago
> But given where the language is already, and given their explicit stated design goals I fully agree, which I tried to say at the end. All I was saying is that you don't need all of the stuff you're talking about to make this work.