> The most obvious use for it is heterogenous containers.

You mean runtime generic container without the benefits of compile-time type checking, opening the developer to runtime type errors purely for ideological reasons...

That Go would benefit from generics doesn't change the fact that there are also lots of use for heterogenous containers. As it is, Go already has "slices" for type safe containers. The fair complaint about Go is it's hard to do other type safe container than the built in "slice" and "map" containers. But the problem is on track to be fixed next year, so it's silly to complain about it now.

It's really hard to take people who complain about Go seriously when they're pretty obviously just zealots who don't know much about the language besides "types good" and "Go bad". My stance: types good in moderation; Go a useful tradeoff of engineering attributes.

> so it's silly to complain about it now.

No it isn't, Go has other flaws stemming from the exact same root cause and it has nothing to do with programming...

> purely for ideological reasons

There are no ideological reasons.

https://github.com/golang/go/commit/dd64f86e0874804d0ec5b713... "Generics may well come at some point."

https://golang.org/doc/faq#generics "A language proposal implementing a form of generic types has been accepted for inclusion in the language. If all goes well it will be available in the Go 1.18 release."

One of the language designers explaining the motivation for adding parametric polymorphism to Go: https://www.youtube.com/watch?v=RIvL2ONhFBI&t=1064s

Explaining the benefits of generics: https://www.reddit.com/r/golang/comments/jditu9/what_do_gene...

From the Featherweight Go paper: https://arxiv.org/pdf/2005.11710.pdf "Recently, the Go team mooted a design to extend Go with generics, and Rob Pike wrote Wadler to ask: Would you be interested in helping us get polymorphism right (and/or figuring out what “right” means) for some future version of Go?"

Yup, it's a common misconception that Go language designers are anti-generics. They wanted to include generics, the reason they were left out is that there was no clear way to include them without significant downsides:

> The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?

> I would be happy to learn about implementations that somehow manage to avoid all three of these bad outcomes, especially if there were good written descriptions (papers, blog posts, etc.) about what was hard and why it's a good approach. I'd also be interested to see good written descriptions of trying one of those approaches and what went wrong (or right).

- Russ Cox (2009): https://research.swtch.com/generic

> do you want slow programmers, slow compilers and bloated binaries, or slow execution times?

Which one did Rust choose?

slow compiler

I think you read my comment as an invitation to debate dynamic vs. static safety checking. That seems like a deeply uninteresting debate. I'm just saying, there's a clear purpose to `interface{}`, and the same pattern shows up (though obviously much less frequently) in Rust.

In the interest of supplying information to the curious, the Rust equivalent is to use an Any trait object with down casting.

https://doc.rust-lang.org/std/any/index.html

The two are orthogonal. Even with generics, languages can have an "escape" type like interface{} which is used/necessary for when you do want (or require) run-time type checking.

That Go would benefit from generics doesn't change the fact that there are also lots of use for heterogenous containers. As it is, Go already has "slices" for type safe containers. The fair complaint about Go is it's hard to do other type safe container than the built in "slice" and "map" containers. But the problem is on track to be fixed next year, so it's silly to complain about it now.

> opening the developer to runtime type errors purely for ideological reasons...

To be fair, there are also language-implementor-laziness reasons.

Runtime safe and statically type checked are two fundamentally different things is my point. Interfaces in most typed languages are static concepts, though there are always exceptions.

You can think of interface{} like Object in Java.

Interfaces in go are simply saying "this thing satifies these properties". interface{} is an interface that anything can satisfy.

I will continue to think of interface{} as Any in Rust.

`interface{}` used as a type is almost exactly `Box<dyn Any>`.