> Go's designers get to use tuple for their favourite use case: returning from a function.

I wouldn't call multiple return values a "tuple". I understand where you coming from, since Python multiple return values are implemented with tuples, but still that point sounds like saying that passing multiple parameters to C functions is "a tuple".

That being said, Go's "simplicity" in design is not only about interface simplicity - it's a lot about implementation simplicity. I imagine that adding tuples would cause a whole lot of complexity that they'd have to deal with. Since Go doesn't have a concept of immutable data types (except consts), tuples would effectively be just variable-typed constant-size slices, which are already implementable as arrays of empty interfaces, but have a runtime overhead...

I hope you see where I'm getting. Creating a language is complex and has a lot of tradeoffs. Then again, I see where you're coming from. I suppose it's a question of whether or not the tradeoffs (the "hypocritical design") is worth the good parts (simplicity of language, which leads to fast compile times, fast runtime, etc.). For me, personally, it is.

Thanks for the input.

> [...] like saying that passing multiple parameters to C functions is "a tuple".

You intended this as a reductio ad absurdum, but you are entirely right. That's how it's handled in eg Haskell.

> I imagine that adding tuples would cause a whole lot of complexity that they'd have to deal with. Since Go doesn't have a concept of immutable data types (except consts), tuples would effectively be just variable-typed constant-size slices, which are already implementable as arrays of empty interfaces, but have a runtime overhead...

I'm not sure that would be a good way to implement tuples. In fact, I suspect it's probably close to the worst way to implement them?

I'd image you'd want to take the machinery you have for structs, and adjust it so that it can deal with anonymous structs with anonymous fields identified by position. (But still preserve all the static typing, instead of throwing your hands up and going with 'variable-typed'.) The runtime overhead would be more or less exactly the same as for structs.

In general, I see tuples as a syntactic sugar over structs and expect them to be compiled like that (or better) in a statically typed language; instead of representing them as some kind of weird slice.

Theoretically, you could probably even implement tuples-via-structs as a preprocessor.

> I imagine that adding tuples would cause a whole lot of complexity that they'd have to deal with.

Yes, so instead of abstaining from tuples, because of these complications, they added a special case for their favourite use case.

Have a look at OCaml for a relatively simple language with less design hypocrisy, and fast compile times and fast runtimes. (Compared eg to the much more complex Haskell.)

> Since Go doesn't have a concept of immutable data types (except consts)

I believe this is incorrect. Strings are immutable, for example. You could also say the same about pointers and maybe a few other data types.

You are right.

Now that I've had more time to think about it, I think the problem of Python-like tuples in Go is that they require Pythonesque everything-is-a-reference paradigm in order to function the same way, otherwise they just act as heterogenous arrays in Go (which exist as arrays of empty interfaces, with a slight runtime cost). Go is mainly value-oriented language like C, with the exception of built-in container types and strings (and maybe a few others that slipped my mind).

I suppose that adding fixed-type pass-by-value tuples would essencially be reimplementing struct. Go doesn't like duplicating functionality.

See my other comment: tuples should be thought of as syntactic sugar over structs, not arrays.

Whether to pass by reference or value and other design decisions should probably be taken (as much as practicable) from the design decisions for structs in your language.