From Python to Go to Rust: an opinionated journey (2018)

I'm trying elixir currently, and it makes me want to rip my hair out. No for loops, no typed parameters, implied returns. Who in the world though any of this was a good idea? IO.puts() refuses to print certain objects (list of ints) and just prints a newline, making it useless for debugging.

I'm very very excited to try Rust, and I'm glad I've been able to choose the languages I work with up to this point in my career.

We've had bugs in prod because of this "feature". It's another bad design decision in golang.

> That's not how engineers work.

Engineers don't leverage automated error checking whenever possible? I think you're confusing engineers with cowboys.

Yes you should have a good idea of what's going on, and strive to make minimal mistakes, and take responsibility for continual improvement. That does not take away from the fact that you should use tools that guide you to the right answer, that catch your mistakes early, and that fail safely.

Safety is not a set of training wheels that a good engineer drops when they're no longer needed.

On top of it, his reason to switch from Go to Rust is laughable at best.

    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.