5 ms·

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.
        erik_seaberg 5y ago
        When I type at a Groovy REPL, an interpreter is using reflection for nearly everything. Same goes for native code that has to use reflection via JNI entry points to call Java. It’s damn useful. At the heart of every debugger is a half-finished reflection API that deserves to be cleaned up and surfaced for language interop and novel kinds of tools.
        pjmlp 5y ago
        Have a look at D and .NET 5 for compile time reflection. Or in Java's case annotation processors. Yes, not everything gets exposed, but it also does the job.

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.
        erik_seaberg 5y ago
        When I type at a Groovy REPL, an interpreter is using reflection for nearly everything. Same goes for native code that has to use reflection via JNI entry points to call Java. It’s damn useful. At the heart of every debugger is a half-finished reflection API that deserves to be cleaned up and surfaced for language interop and novel kinds of tools.
        pjmlp 5y ago
        Have a look at D and .NET 5 for compile time reflection. Or in Java's case annotation processors. Yes, not everything gets exposed, but it also does the job.