An empty interface should be effectively useless. What could it possibly do!? This pattern is much more like a dynamic container with a type tag.
https://go.googlesource.com/proposal/+/master/design/15292/2...
Generics do not obviate the need for interface{} or the described use case of map[string]interface{}
interface{} is like Java or C# object. It packages a type and a value in a single value that can be queried at runtime to extract the underlying value in a type safe matter.
When people use map[string]interface{] it's because they don't know the type of value at compile time.
Go maps are actually not generic in the same way they are in other languages, there is just a single map struct with type descriptors used to do some compiler magic: https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...
For generics what you want is not interface{}, which says nothing, but a type T that has meaningful constraints.
Interfaces in go are simply saying "this thing satifies these properties". interface{} is an interface that anything can satisfy.
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?