> The weird "return tuple" , which obviously just exists for errors because there is not a single other place where you can use tuples in the language

MRV, go does not have tuples.

Go is not the only language with MRV (as a special case) and they’re not necessarily bad, iirc Common Lisp uses them as auxiliary data channels and has a whole host of functions to manipulate and refit them.

Go is singularly incompetent at MRVs though, in the sense that only syntax and builtin functions get access to variable arity (e.g. if you access a map entry you can either get one return which is a value, or two which are the value and whether the key is/was in the map). So MRVs mostly end up being worse tuples infecting everything (e.g. iterators needing Iter and Iter2 because you can’t just yield tuples to for loops).

▲

pwdisswordfishz 7 months ago | parent | next [-]

> MRV, go does not have tuples.

> MRVs mostly end up being worse tuples

I think you noticed yourself that you’re getting too hung up on terminology. Multiple return values are a half-hearted, non-reified version of tuples.

▲

masklinn 7 months ago | parent | next [-]

No, MRVs can actually offer useful properties and features, that is what they do in Common Lisp. That Go does not do that has nothing to do with MRVs.

	▲	erik_seaberg 7 months ago \| parent [-]
		f(g(), h()) can't work with MRVs, only f(g()). multiple-value-list, multiple-value-call, and quietly ignoring unneeded values makes them much more usable.

▲

biorach 7 months ago | parent | prev [-]

Which is what they said. I'm not sure what point you're making

▲

robocat 7 months ago | parent | prev | next [-]

> MRV

Acronym for Multiple Return Values https://gobyexample.com/multiple-return-values

▲

baranul 7 months ago | parent | prev [-]

I've noticed that many people make this mistake with Go and other languages that use MRV (multiple return values). It seems that people who come from a language with tuples have a hard time dealing with the difference or realizing they are different.

It's a plus versus minus type of situation, where both have their advantages and disadvantages, along with a number of workarounds and alternatives that can be used.

In many cases, people can return arrays, hash maps, or structs in place of tuples. That looks like the reasoning in Go, where if the person needs something beyond MRV, they can use the other options available. Go and various other languages, didn't need or didn't want to lean on tuples as much.

	▲	masklinn 7 months ago \| parent [-]
		> It seems that people who come from a language with tuples have a hard time dealing with the difference or realizing they are different. The problem is that Go only has the drawbacks of MRV and leverages essentially none of the advantages. > Go and various other languages, didn't need or didn't want to lean on tuples as much. As far as I’m concerned go would be a strictly better language if it had tuples (or even just the ability to unpack structs). All the nonsense about foo/foo2 to handle both single and multiple results would go away, and pretty much the only thing which would be lost is individual addressing of MRVs for named return values, which is easy enough to replace by naming the return struct and going through it.