I don't necessarily disagree, but it depends on your goals as a language designer. I think it's OK to sacrifice a niche feature for improved readability in the common case. Anonymous structs are not as fundamentally useful as e.g. anonymous functions.
> Also assumes the magical splatting of MRVs is a good thing in the first place.
IMHO, G(F()) reads nicer than some variant of G(*F()) or G(F()...). Lua does this too, and is (not unlike Go) considered a simple and elegant language.
> Which assumes this code matters much, outside of errors for which intermediate processors can just take... a tuple of a value and an error.
Then you'll sooner or later find yourself writing a G((a, b)), which again, I think is a net loss to readability.
I think my argument would've been much stronger if Go had had generics in 1.0, and the stdlib/ecosystem wasn't already full of MustParse's and MustCompile's. But in that case we could've had a Result type as well.
> Also assumes the magical splatting of MRVs is a good thing in the first place.
IMHO, G(F()) reads nicer than some variant of G(*F()) or G(F()...). Lua does this too, and is (not unlike Go) considered a simple and elegant language.
> Which assumes this code matters much, outside of errors for which intermediate processors can just take... a tuple of a value and an error.
Then you'll sooner or later find yourself writing a G((a, b)), which again, I think is a net loss to readability.
I think my argument would've been much stronger if Go had had generics in 1.0, and the stdlib/ecosystem wasn't already full of MustParse's and MustCompile's. But in that case we could've had a Result type as well.