News for hackers. Stuff that matters.
Re:Go: What We Got Right, What We Got Wrong by ncruces on Friday January 05, 2024 @08:33AM (#38878852)
Yes. There are long standing feature requests for (e.g.) the reflect package that simply don't get done because they'd break this assumption and/or force further indirection in hot paths to support "no code generation at runtime, ever".

Packages like Yaegi (that offers an interpreted Go REPL) have "know limitations, won't be addressed" also because of these assumptions.

https://github.com/golang/go/issues/4146

https://github.com/golang/go/issues/16522

https://github.com/traefik/yaegi?tab=readme-ov-file#limitati...

Re:Go: What We Got Right, What We Got Wrong by Guvante on Friday January 05, 2024 @03:09PM (#38884161)
If they wanted an REPL having an interpreted Go compiler isn't unheard of in the space.

It isn't like a hypothetical C++ REPL would use unmodified LLM under the hood after all.

Re:Go: What We Got Right, What We Got Wrong by ncruces on Saturday January 06, 2024 @07:45AM (#38890984)
Then just use Yaegi, which I linked to above.

It has the limitations mentioned, which are necessary to make duck-typed interface calls reasonably efficient, if you assume no code generation at runtime, ever.

There's really no other way. If you don't know before hand all the interfaces that might exist, and/or all the types that might implement them, interface method calls would necessarily either need to be JIT generated, or a string based hash map lookup (runtime reflection, which exists, but is slow).

Go avoids both by knowing statically at compile time the list of all interface and the list of all types that can ever possibly implement them and building vtables for those.