3 ms·

By that logic, then currently, if you want cool generics abilities, there is Java for you. No need for Go. But then there's this spec for generics, so obviousl

by dagss 8y ago

By that logic, then currently, if you want cool generics abilities, there is Java for you. No need for Go. But then there's this spec for generics, so obviously one wants to develop Go further. And I think it's a valid question why generics in particular is chosen instead of other ways of solving the same problem.

gameswithgo 8y ago
>By that logic, then currently, if you want cool generics abilities, there is Java for you. No need for Go. Java has one of the least good generics implementations of modern languages. I suggest C#, or even better, F# if you want to make heavy use of them =) Generics compared to templates keep the language simpler, solve the most common cases of code repetition, and can easily provide good error messages and runtime performance.
- thethirdone 8y ago
  > Java has one of the least good generics implementations of modern languages. I suggest C# ... What are the particular differences that make you suggest C# over Java generics? As far as I am aware they are nearly identical for practical use (as language constructs). Things like Java using type erasure don't actually affect the language much only the particular compiler implementations.
  - int_19h 8y ago
    They affect the language a lot in non-trivial applications. For example, you can't implement the same generic interface with different type parameters, even when it is perfectly meaningful: suppose we have an interface Convertible<T> that objects that can be converted to T should implement - why can't an object implement Convertible<int> and Convertible<string> at the same time? Ditto with overloads - suppose you have a family of functions like frob() that apply to ints and doubles - so there's frob(int) and there's frob(double). So far, so good. Now, you want to add helpers to do the same for collection - and so there's frob(Iterable<int>) and frob(Iterable<double>)... except that doesn't work, because you can't overload on a generic interface, since the method signature has that information erased entirely. And then, of course, it breaks Reflection. Which is not so common in application code, but has many valid uses in the libraries.

by dagss 8y ago

gameswithgo 8y ago

>By that logic, then currently, if you want cool generics abilities, there is Java for you. No need for Go. Java has one of the least good generics implementations of modern languages. I suggest C#, or even better, F# if you want to make heavy use of them =) Generics compared to templates keep the language simpler, solve the most common cases of code repetition, and can easily provide good error messages and runtime performance.

thethirdone 8y ago
> Java has one of the least good generics implementations of modern languages. I suggest C# ... What are the particular differences that make you suggest C# over Java generics? As far as I am aware they are nearly identical for practical use (as language constructs). Things like Java using type erasure don't actually affect the language much only the particular compiler implementations.
- int_19h 8y ago
  They affect the language a lot in non-trivial applications. For example, you can't implement the same generic interface with different type parameters, even when it is perfectly meaningful: suppose we have an interface Convertible<T> that objects that can be converted to T should implement - why can't an object implement Convertible<int> and Convertible<string> at the same time? Ditto with overloads - suppose you have a family of functions like frob() that apply to ints and doubles - so there's frob(int) and there's frob(double). So far, so good. Now, you want to add helpers to do the same for collection - and so there's frob(Iterable<int>) and frob(Iterable<double>)... except that doesn't work, because you can't overload on a generic interface, since the method signature has that information erased entirely. And then, of course, it breaks Reflection. Which is not so common in application code, but has many valid uses in the libraries.