I know there is a lot of discussion about generics, but I am not sure if that is missing the point. I mean 'generics' sounds like a complex concept from the java development and I am uncertain if that's really what we need in go.
From my experience I think we should talk about container formats because they make 80% of what we would like to have generics for. Actually, go feels as if it has only two container data structures: Slices and Maps. And both feel as if they are pretty hard coded into the language.
Yes, I am sure there are more container formats and it is possible to build your own, but I think it is not easy enough.
> I mean 'generics' sounds like a complex concept from the java development and I am uncertain if that's really what we need in go.
That's inane and insane. Java generics do almost nothing, they don't even exist at runtime in a language with (much like Go) heavy runtime semantics. Here's what Java's generics do: get typechecked, and insert implicit casts.
> What does that mean? It is not easy enough what? To write containers? To have generics?
Actually, I meant it is not easy enough to build container formats (maybe due to the lack of generics).
Btw. I will not continue this conversation as I am tired of getting insulted (inane and insane), getting downvoted for merely asking questions and you editing your post without labeling it. Just saying.
1. the empty interface does not do the first one, and thus does not allow writing typesafe structures and code
2. and it requires significant expense of explicit casts which are not just sanity checks (which is what they are in java, due to type system weaknesses)
> they make 80% of what we would like to have generics for
I regularly use generics in other languages for tasks unrelated to "containers"/data structures. They allow me to write less code and have the compiler check my mistakes.
Containers are frequently where people start with parameterized types, but once you are in the habit of using them actively that's rarely where you stop.
> once you are in the habit of using them actively that's rarely where you stop.
Eh. Many people don't ever go beyond that and it's fine, containers-type structures (to which I include stuff like futures or option types) and functions working on those are by far the most common use case.
From my experience I think we should talk about container formats because they make 80% of what we would like to have generics for. Actually, go feels as if it has only two container data structures: Slices and Maps. And both feel as if they are pretty hard coded into the language.
Yes, I am sure there are more container formats and it is possible to build your own, but I think it is not easy enough.