4 ms·

Back when generics were introduced to Java I felt the same thing. I had been doing Java for years at that time. I had also been working for Sun, so of course I

Back when generics were introduced to Java I felt the same thing. I had been doing Java for years at that time. I had also been working for Sun, so of course I was exposed to it. I was very negative towards generics and had similar arguments as you. It didn't take long before I changed my mind. I'd never want to write Java without generics again. I'm not saying you're going to have the same experience, but I would suggest you give it a try before dismissing its value.

silisili 5y ago
Thanks for your experience, really. Here's hoping.
pkulak 5y ago
Does Go generics have type erasure? If not, OP can expect and even better journey.
- mseepgood 5y ago
  No, they don't have type erasure.
  - erik_seaberg 5y ago
    Go is getting monomorphization, separate machine code for each type specialization of a generic function. I assume reflection will choose the one for the args you want to pass, or make you do that.
    - masklinn 5y ago
      > I assume reflection will choose the one for the args you want to pass, or make you do that. According to the spec: > It's impossible for non-generic code to refer to generic code without instantiating it, so there is no reflection information for uninstantiated generic types or functions. You won't be able to reflect a generic List or List[T] at all which… makes sense, I think? `reflect` works on values at runtime, so it necessarily works with instantiated types as you can't have a value of an un-instantiated (generic) type: what would you give to `reflect.TypeOf` which could return an uninstantiated generic type?
      - erik_seaberg 5y ago
        I was thinking of generic functions rather than (non-generic) methods on generic types. Unfortunately it looks like reflection can’t look up functions in a module at all, which is surprisingly broken.
        masklinn 5y ago
        > Unfortunately it looks like reflection can’t look up functions in a module at all, which is surprisingly broken. The more time passes the more I think ubiquitous reflection in statically typed languages is what's broken (and a reflection (heh) of deep limitations of the language). So while I could understand having issues with generics breaking existing reflection code (which doesn't seem to be the case), I'm not going to be sad over reflection having never supported toplevel functions in the first place.
        erik_seaberg 5y ago
        What good are top-level functions if they’re unreachable from any script interpreter or management RPC server or other languages’ FFI?
        4ad 5y ago
        Functions are useful because you can call them from your program.
        masklinn 5y ago
        I fail to see what any of this has to do with reflection. > any script interpreter What are you even talking about. > or management RPC server I would very much expect RPC endpoints to be opted in explicitly and statically. > or other languages’ FFI? I fail to see why Go-level reflection would be involved in that in any capacity. > What good are top-level functions You can call them? From your go code? Are you saying rust or C can't be because they don't have reflection? That's a strange position.
- 4ad 5y ago
  There are two meanings of "type erasure". One concerns the user, the other the compiler writer. When most users people ask about type erasure, they ask whether types are erased when compiling the reflection information for polymorphic values (like Java does). Go doesn't have polymorphic values, so the question doesn't apply. Type erasure means something more general than that to compiler people. Type erasure refers to whether you can compile code while erasing its type, and it's generally a useful property. In general statically-typed programming languages are implemented with type erasure, while dynamically-typed languages are not. Of course, since Go has reflection, it can't do type erasure. Interfaces also conflict with type erasure somewhat, though as expected, during the code generation types are erased as much as possible. As a comparison, Rust does type erasure fully.
  - iso8859-1 5y ago
    So Haskell has type erasure only for data types that do not derive Typeable?
    - tome 5y ago
      No, because all types have a Typeable instance! Haskell has type erasure, and then using Typeable adds the type information back exactly where it is needed.
mypalmike 5y ago
With Java, I didn't find it to be either a huge win or a major loss. And I still don't. It's basically window dressing that lets you avoid casts in certain obvious places where they weren't particularly problematic anyhow.
- hyperman1 5y ago
  It's more than window dressing. A year ago I added correct generics to about 50 000 lines of Java, an old module in a bigger program. The change was mostly mechanical, removing casts and adding signatures. I found a few places where refactoring had left behind a wrong type cast. Production logs demonstrated actual crashes corresponding to these cast. There were bugs in the issue tracker, marked unresolvable.
  - mypalmike 5y ago
    Interesting, I'd never encountered such bugs, but it makes sense

silisili 5y ago

Thanks for your experience, really. Here's hoping.

pkulak 5y ago

Does Go generics have type erasure? If not, OP can expect and even better journey.

mseepgood 5y ago
No, they don't have type erasure.
- erik_seaberg 5y ago
  Go is getting monomorphization, separate machine code for each type specialization of a generic function. I assume reflection will choose the one for the args you want to pass, or make you do that.
  - masklinn 5y ago
    > I assume reflection will choose the one for the args you want to pass, or make you do that. According to the spec: > It's impossible for non-generic code to refer to generic code without instantiating it, so there is no reflection information for uninstantiated generic types or functions. You won't be able to reflect a generic List or List[T] at all which… makes sense, I think? `reflect` works on values at runtime, so it necessarily works with instantiated types as you can't have a value of an un-instantiated (generic) type: what would you give to `reflect.TypeOf` which could return an uninstantiated generic type?
    - erik_seaberg 5y ago
      I was thinking of generic functions rather than (non-generic) methods on generic types. Unfortunately it looks like reflection can’t look up functions in a module at all, which is surprisingly broken.
      - masklinn 5y ago
        > Unfortunately it looks like reflection can’t look up functions in a module at all, which is surprisingly broken. The more time passes the more I think ubiquitous reflection in statically typed languages is what's broken (and a reflection (heh) of deep limitations of the language). So while I could understand having issues with generics breaking existing reflection code (which doesn't seem to be the case), I'm not going to be sad over reflection having never supported toplevel functions in the first place.
        erik_seaberg 5y ago
        What good are top-level functions if they’re unreachable from any script interpreter or management RPC server or other languages’ FFI?
        4ad 5y ago
        Functions are useful because you can call them from your program.
        masklinn 5y ago
        I fail to see what any of this has to do with reflection. > any script interpreter What are you even talking about. > or management RPC server I would very much expect RPC endpoints to be opted in explicitly and statically. > or other languages’ FFI? I fail to see why Go-level reflection would be involved in that in any capacity. > What good are top-level functions You can call them? From your go code? Are you saying rust or C can't be because they don't have reflection? That's a strange position.
4ad 5y ago
There are two meanings of "type erasure". One concerns the user, the other the compiler writer. When most users people ask about type erasure, they ask whether types are erased when compiling the reflection information for polymorphic values (like Java does). Go doesn't have polymorphic values, so the question doesn't apply. Type erasure means something more general than that to compiler people. Type erasure refers to whether you can compile code while erasing its type, and it's generally a useful property. In general statically-typed programming languages are implemented with type erasure, while dynamically-typed languages are not. Of course, since Go has reflection, it can't do type erasure. Interfaces also conflict with type erasure somewhat, though as expected, during the code generation types are erased as much as possible. As a comparison, Rust does type erasure fully.
- iso8859-1 5y ago
  So Haskell has type erasure only for data types that do not derive Typeable?
  - tome 5y ago
    No, because all types have a Typeable instance! Haskell has type erasure, and then using Typeable adds the type information back exactly where it is needed.

mypalmike 5y ago

With Java, I didn't find it to be either a huge win or a major loss. And I still don't. It's basically window dressing that lets you avoid casts in certain obvious places where they weren't particularly problematic anyhow.

hyperman1 5y ago
It's more than window dressing. A year ago I added correct generics to about 50 000 lines of Java, an old module in a bigger program. The change was mostly mechanical, removing casts and adding signatures. I found a few places where refactoring had left behind a wrong type cast. Production logs demonstrated actual crashes corresponding to these cast. There were bugs in the issue tracker, marked unresolvable.
- mypalmike 5y ago
  Interesting, I'd never encountered such bugs, but it makes sense