Re:Generics enabled by default in Go tip
by erik_seaberg on Saturday August 21, 2021 @08:03AM
(#28256292)
What good are top-level functions if they’re unreachable from any script interpreter or management RPC server or other languages’ FFI?
[ Parent
| on HN ]
Re:Generics enabled by default in Go tip
by masklinn on Saturday August 21, 2021 @10:02AM
(#28257093)
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.
Re:Generics enabled by default in Go tip
by erik_seaberg on Saturday August 21, 2021 @07:29PM
(#28261527)
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.
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.