> Go would have been a far simpler language had it originally shipped with generics, iterators, and sum types.
You forgot tuples.
You forgot tuples.
func F() (A, B) { ... }
func G(a A, b B) { ... }
G(F())
func H(ab (A, B)) { ... }
(Before you suggest a Python-like star operator, personally I consider using it for non-homogenous arguments about as hygienic as keeping your toothbrush and dirty socks in the same drawer.)
Which assumes this code matters much, outside of errors for which intermediate processors can just take... a tuple of a value and an error.
Also assumes the magical splatting of MRVs is a good thing in the first place.
> (Before you suggest a Python-like star operator, personally I consider using it for non-homogenous arguments about as hygienic as keeping your toothbrush and dirty socks in the same drawer.)
That is literally what Go currently does for MRVs, except opt-in instead of magical.
There is nothing about such splatting which wouldn't work with proper tuples, if anything it's the opposite. It is, essentially, the value side of `uncurry`.
> 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.