3 ms·

There isn’t a single language which has implemented genetics without those expanding to the complexity of C++ generics. It turns out most of the complexity is e

There isn’t a single language which has implemented genetics without those expanding to the complexity of C++ generics. It turns out most of the complexity is essential: - need overloading to support instantiation - need type functions/associated types. For example what type is inside this container? - need operator overloading so you can substitute generic types into assignment expressions. For example notions of equality. - need duck typing or traits to communicate capabilities The two simplifications which have historically worked are to use dynamic types, or to use code generators.

VirusNewbie 2y ago
So the idea of type classes are so scary they went with shitty generics?
- grandempire 2y ago
  Yes.
rowanG077 2y ago
It depends on what you mean with generics. If it's only parametric polymorphism and ad hoc polymorphism then I would Haskell solves it trivially and very easy to understand. If you mean it to include full "template" metaprogramming or type level programming then I'm not sure.
- grandempire 2y ago
  If go copies this design from Haskell would it look simple?
  - rowanG077 2y ago
    Sure. Type classes are extremely simple. Go generics are already superficially similar to type classes.
    - grandempire 2y ago
      Suppose I have a generic array-like collection containing a type a and I want to write a map function to take it to a collection of type b. In Haskell this is something like map :: (a->b) -> C a -> C b Can you share what that would like in Go with type classes?
      - rowanG077 2y ago
        It's possible to define an map function for a container today https://go.dev/play/p/zcP6FZcBzyC https://go.dev/play/p/zcP6FZcBzyC You can also define an fmap interface that doesn't actually map the type, but can apply function that do not change the type: https://go.dev/play/p/836wr3nuw4U https://go.dev/play/p/836wr3nuw4U But currently I don't think it's possible to combine this. That is have an fmap as it is in Haskell. You would need to capability to add generic arguments to an interface. It could look something like this: https://go.dev/play/p/E_emmGUOoIz https://go.dev/play/p/E_emmGUOoIz
        grandempire 2y ago
        This is very helpful. Thanks.

VirusNewbie 2y ago

So the idea of type classes are so scary they went with shitty generics?

grandempire 2y ago
Yes.

rowanG077 2y ago

It depends on what you mean with generics. If it's only parametric polymorphism and ad hoc polymorphism then I would Haskell solves it trivially and very easy to understand. If you mean it to include full "template" metaprogramming or type level programming then I'm not sure.

grandempire 2y ago
If go copies this design from Haskell would it look simple?
- rowanG077 2y ago
  Sure. Type classes are extremely simple. Go generics are already superficially similar to type classes.
  - grandempire 2y ago
    Suppose I have a generic array-like collection containing a type a and I want to write a map function to take it to a collection of type b. In Haskell this is something like map :: (a->b) -> C a -> C b Can you share what that would like in Go with type classes?
    - rowanG077 2y ago
      It's possible to define an map function for a container today https://go.dev/play/p/zcP6FZcBzyC https://go.dev/play/p/zcP6FZcBzyC You can also define an fmap interface that doesn't actually map the type, but can apply function that do not change the type: https://go.dev/play/p/836wr3nuw4U https://go.dev/play/p/836wr3nuw4U But currently I don't think it's possible to combine this. That is have an fmap as it is in Haskell. You would need to capability to add generic arguments to an interface. It could look something like this: https://go.dev/play/p/E_emmGUOoIz https://go.dev/play/p/E_emmGUOoIz
      - grandempire 2y ago
        This is very helpful. Thanks.