So much for all those who claim generics remain overwhelming concern for Go developers.
So much for all those who claim generics remain overwhelming concern for Go developers.
There are, of course, some users, that can make substantial comments about design, but they cannot be represented in a survey.
Not really, since you can always just use interface{} for everything and get all the dynamism back.
Generics is when you want to have both (dynamism and safety).
Other similar answers:
2% easy to learn, 2% simple syntax, 2% simple language, 1% easy to use, 1% easy to write, 1% ease of use
In the case of generics there's another 1% answer on generic
I mean, parametric polymorphism is achievable with different approaches...
In Go, you don't have subclassing, so you cannot implement YourClass<T extends SomeAncestor>.
There is no opposition between ADT and generics. In fact most language that have ADT have generics…
> In Go, you don't have subclassing, so you cannot implement YourClass<T extends SomeAncestor>.
There is no link between generics and inheritence, functionnal languages usually don't have OOP mechanism but they still have generics.
if err != nil {
return nil, err
}
blocks. But it would most definitely be a pain in the ass to integrate this with the toolchain.