This is your big hangup with Go? You added a new field, didn’t use that field anywhere, and the compiler didn’t complain? I’ve heard a lot of valid criticisms of the language but this is a new one for me.
type Sample struct {
A int
B int
}
The name-based method allows arbitrary elision of fields, which will be initialized to their zero value. This includes Sample{}, which will be interpreted as a name-based initialization that specified no fields.
The position-based method requires all fields to be specified, in order, with the correct type, or it's a compile-time fail.
So if the author of the article could have gotten the latter behavior with a slight syntax tweak.
This would not necessarily entirely satisfy, though, since you can't do any mix-and-match, and in particular, it can be nice to have names on the larger structs even if you want them to be fully initialized, but there is no in-between. But, nevertheless, if you are willing to pay for the behavior that the compiler will complain on any type-changes to the struct, including growing or shrinking, Go has that.
It seems to be the Go community's "best practice", above my objections, to claim that all struct initializations MUST use the name-based initialization and that positional-based inits is a mistake, on the theory that if structs change and add fields it's important for all uses of structs to continue compiling without changes. If the author's introduction to Go came from a tutorial from someone who believed that, they could easily have picked that up mistakenly as a characteristic of the language itself.
My objection is that there's a time and a place for each behavior, and there have been plenty of times I've been grateful for the compiler pointing out every place I need to change my struct to include a new member because I could tell it was a "tuple-like" struct that should always be initialized with all the fields. You can argue with the putative "best practice" or agree with it, but fortunately it doesn't really matter because you can do the one you want regardless of what the community thinks. There is no chance either method is ever going to be removed.
1) It's much more difficult to read since you have to know the position of elements of the struct
2) You swap one compile time error for another: in the case you add and remove a field of the same type, it's entirely possible the program will compile fine if you use the positional initialization instead of the named one.
#2 makes me think that the author would still be unsatisfied
At least the Go editor I use (GoLand by JetBrains, one of the more popular ones) will display the names of all the fields in positional initializers inline with the code (just as they would be in a named initializer), so it's pretty much the same readability-wise. There's a special color for these automatic labels that indicates they aren't actually part of the document.
> in the case you add and remove a field of the same type, it's entirely possible the program will compile fine
True although I think it's easier to work around this (by fixing the compile errors from removing the old field before adding the new one).
One other reasonable alternative for OP in Go might be to simply use initialization functions (NewSample() or sample.InitWithX()) for certain structs. It's a bit more flexible with the ability to have multiple initializers and non-zero default field values (and of course also solves the issue of generating compile errors in the rest of the code when new fields/parameters are added).
Edit: spelling
1. Go doesn't follow "you pay for what you use" model.
2. Go isn't too deeply invested in compilation as means for catching errors.
Above are not binary language decisions. If you go in one direction strongly then there are consequences in other. Therefore all languages chose some balance point (aka compromises). Go has chosen a balance point that is weaker than Rust (and may be even C++) but stronger than Python.
To be fair, isn't that implied since Go uses a GC? The "pay for what you use" model is only really viable for languages that don't rely on a fixed GC runtime. (You could have "pluggable" GC libraries like the Boehm collector for C/C++, but those imply very different tradeoffs.)
It's not "you" in the traditional formulation. It's "CPU." You, the programmers, often have to pay continuously for "you pay for what you use."
Except when you've imported a package you're not currently using, that is a mortal sin :)
Keep in mind that dataclass defaults suffer from the same "mutable default arguments" issue as function parameters.
Hell, just the other day I complained to my backend team that the PubSub event was passing null for a non-optional array, and it was traced to the Go code declaring a map variable without ever initializing it. The compiler never caught that, it wasn't until it hit my Swift code that it became apparent.
We've had bugs in prod because of this "feature". It's another bad design decision in golang.
There are APIs with autogenerated structs that span a lot of fields (even thousands)... Imagine having to initialize each field when you just want... the default zero value...
I think each of these three languages have made the correct choice, given their design ideals.
> I think each of these three languages have made the correct choice, given their design ideals.
I feel that's kind of side-stepping the issue though. The approach that golang took could match their design goals, but it doesn't mean that those goals aren't a bad idea in the first place.
On the other hand, golang does not have the ability to prevent "default constructors", and the fact that it has no ability to make types file private further makes this an issue.
I know, but that's not what I'm referring to here. I'm referring to someone writing:
type A struct {
A int
B int
}
a := A {A: 1, B: 2}
The code continues to compile, with `C` being initialized to 0, which can be incorrect.
In Java or C#, you'd add a third value to the constructor, resulting in a compile time error for all constructor invocations.
As I said, I've seen this issue come up in production resulting in bugs.
I don't believe that TypeScript, which is mainstream, has zero values if strict mode is enabled. (I could be wrong though; plugging all the "undefined" leaks is hard in JS.)
One use-case where this is really painful: I like to encode sum types in Go using an interface with a private dummy method + structs that implement that. I then have a function "match" that takes one function per struct. It's nice to be able to pass these functions as a record since it gets ugly, but due to Go allowing omitted functions to be nil, if I add a case to the sum, I open myself up to NPEs everywhere. If Go had a warning for missing struct fields, it would tell me all the places I'd need to handle a new case.
Enforcing the initialization of all fields achieves relatively little given that public fields could easily be modified elsewhere. Requiring initialization to anything more specific than an automatic zero value is only useful in languages that have read-only fields.
So the only way to handle this in Go is to make struct fields private or accept that all combinations of public field values are valid (including the zero value) and deal with it at the point of use (or rather at all points of use).