Doing nothing is the point; it serves the same purpose as a `void*` in C, except that there are (runtime-) safe ways to take a value out of `interface{}` and back to its concrete type in Go. 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...
To be fair, there are also language-implementor-laziness reasons.
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.
No it isn't, Go has other flaws stemming from the exact same root cause and it has nothing to do with programming...
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?"
> 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
Which one did Rust choose?
Interfaces in go are simply saying "this thing satifies these properties". interface{} is an interface that anything can satisfy.