> * Easy to read
The motivating examples of this whole proposal are examples where one reads the code and the semantics are unclear.
> PPS: If you think multiple returns and sumtypes solve the same thing, you've not thought very hard on the subject...
The stereotypical example of multiple returns in Go is functions that return val, err when they mean that they return one of a value or an error. Which is what sum types do.
The point is that with real sum types, the compiler will enforce that you return exactly one of a value or an error, whereas in Go, you're just supposed to do so, and it's possible to write code that mistakenly returns both or neither.
One of Go's core missions is to keep the number of concepts users need low. Multiple returns encompass the error use case and others.
But I would not personally design a new language without sum types or some other similarly strict solution for the kind of programming that will encounter errors.