Were multiple return values Go's biggest mistake?

Let’s not create confusion by messing around with definitions. It’s important to have standard terminology that has the same meaning across different programming languages, otherwise you can’t have a meaningful discussion about programming language design.

The definition of currying is this: a function is curried if you call it with some of its arguments, and it returns another function that when called consumes more of its arguments. You can implement curried functions in Python, Javascript, and any language that supports function closures.

All Python method calls are curried, as a built-in feature. It doesn’t matter that the Python community doesn’t use this terminology.

What I originally said is that this feature of Python was part of the inspiration for curried method calls in the new language I am developing. I was trying to communicate by using exact language that has a generally accepted meaning.

There’s Haskell and other languages with currying :D

(Just joking. I don’t even know if I would say that Haskell functions have multiple arguments or just one.)

From another site’s thread about this same blog post, I wrote:

–

I love multiple return values, and I’m glad Go included it. [..] The way we addressed this in Ecstasy (xtclang) was to imagine the junction between the call site and the function as a nexus of sorts, where the caller can indicate that they want multiple result values back, or the caller can indicate that they want a tuple of result vales back, and the callee doesn’t know and doesn’t care. In most cases, the design allows for the elimination of allocation of a tuple altogether, although if the caller wants to get and hold onto a tuple, the allocation is going to be realized. So given some function (Boolean, Int, String, Int[]) foo(), the caller can do any of:

Int x = foo();
(Int x, String s) = foo();
(Int x, String s, Int[] a) = foo();
(_, String s, Int[] a) = foo(); // etc.
Tuple t = foo();
Tuple<Int, String, Int> t = foo();
// this enters the if block iff the Boolean return is True
if ((Int x, String s, Int[] a) := foo()) {...}

… and so on.

The same applies to parameters as well, in that the caller can provide the parameters as a tuple instead of the individual, separate values. This doesn’t get used very often outside of reflection, but it is quite useful when you need it. The compiler does all of the heavy lifting, which includes type safety enforcement, etc.

proposal: spec: tuples as sugar for structs

Interesting one. I wrote quite some code in Limbo. It had tuples. You would normally have to unpack the tuple to access the items. But you could also access the fields with .t0, .t1 and so on. I don’t think that was in the language spec. But it was used. Example: https://github.com/mjl-/ssh/blob/master/appl/cmd/sftpfs.b#L742

Btw, in practice, I just sometimes miss tuples for sending over channels. Those are often composite types that I don’t use anywhere else. It’s a little cumbersome to define a type for it. But it’s also not a big deal, and probably helps readability.

For those interested, see https://www.vitanuova.com/inferno/papers/limbo.html. Can’t link to sections… Look for tuple. Example:

chan of (int, string)

c <-= (123, "Hello");

It’s all just about the set of design compromises chosen by authors to achieve their goals, no more no less.

The same cop-out all the time.

Go is very poorly designed and archaic. It’s not simple, just primitive. It’s design if full of glaring mistakes. Golang could have been a way better designed language, without compromising the good properties that make it successful. It’s not some “set of design compromises” that made all the crappy parts neccessary. But it doesn’t matter. It is successful irrespective of how poorly it is designed, because technologies being successful have very little to do with their design. Just like the most popular music is generally cheap pop on autotune, and most popular movies are are 15th version of avengers. Or how JS has a very poor design, but used everywhere, because … web browser.

Go had Google’s support which gave a lot of people a lot of confidence it’s worth investing in it, and it’s easy concurrency and deployment story met the needs of growing market of scalable web-first systems, and every growing demand for replaceable mid-tier developers that just need to get the job done. And most real life backend systems just shuffle data between http endpoint and a database, and even if you screw up bunch of things in it, liveness probe is just going to restart it, or the user will complain and try again. And generally most software is only as good, as absolute bare minimum required for the business not to suffer too much.

I think multiple-return actually has another additional poor interaction which the article doesn’t touch on, which is how it changes the behavior of the := operator in two confusing ways.

The classic example I have here is that in Go, unused variables are an error, so err := f() will be an error if you ignore the err variable entirely.

However, if you have multiple return, x, err := f(), ignoring that err variable might be a compiler error depending on other context. Specifically:

// compiler error, 'declared and not used: err'
func f1() int {
   val, err := someFunction()
   return val
}

// but this compiles fine, even though the second 'err' isn't used
func f2() int {
   val1, err := someOtherFunction()
   if err != nil { return 0 }
   val2, err := someFunction()
   return val1 + val2
}

The reason for that is that := declares a variable, except for in multiple return it assigns any existing variables with the same name if at least one variable (val2 in this case) is new. That’s confusing, and leads to real bugs in my experience.

The second confusing interaction here is that the declare-vs-assign thing also changes the type of variables based on surrounding code.

For example, if you have:

func concreteError() (*os.File, *os.PathError) {
	return nil, &os.PathError{}
}

func main() {
	// f, err := os.Open("/file") // return type (*os.File, error)

	f2, err := concreteError()
	// 'err' is of type '*os.PathError' here, but if someone later, without
	// editing this line, uncomments out the first line in main, 'err' changes to
	// type 'error' here, it becomes an interface. This is weird spooky action at
	// a distance
}

I’ve seen both of these issues a few times in practice, with the first one being more of an issue, and the second not really occurring for err (since every uses the error interface), but rather for generic “value” names, when someone accidentally re-uses the same variable name for an interface and non-interface type.

I loved this post. Thanks for sharing it. Multiple value returns used to be a source of contention with new gophers that often would ask “can I use a struct here instead?”

My guess is that the core team is targeting a non-backward compatible release sometime soon. The reason is that i say so is that they have been working on a tool to modernize go source code bases. Sort of a supercharged “go fix”. If they decided to draw inspiration from Haskell and use sum types for value and error handling in a non-backward compatible way, the modernizer tool could make this idea viable. Ah, and also, go.mod now support compiler selection, so technically, they can make a major release the covers this possibility while giving time to the ecosystem to migrate.

This (of course) doesn’t compile since (string, error) is not a type

This is not a bug but a feature of the language. It forces you to do something about the error, log and ignore it, or do an early return, or do something else. This brings the code to production quality much more quickly for me than other languages.