3 ms·

I wouldn't call it "huge". Using net/rpc to emulate shared library plugins has been the primary recommended technique to anyone raising the question for a while

• eternalban 12y ago
  Agreed, not huge, and well known. Code gen is probably the most sensible way to approach the static nature of Go (and also generics, when all is said and done ;). While it is true that the pluggable platform x on Go should allow for any compliant plugin, at deployment time, the plugin set is known and effectively static. Irony here is that given that the chaining of tools is emerging as the most natural way to build up the feature sets, the fast compile time may not be so fast anymore.
  • skybrian 12y ago
    If you use go generate [1], you check in the generated code, and only the author of a library pays the cost of code generation, not all the downstream dependencies. You pay a price for not recompiling from the real source; in particular, after a security bug is fixed in a code generator, the downstream libraries won't automatically regenerate their code. On the other hand, it's no worse than ecosystems such as Maven or Linux distros where people commonly download binary libraries rather than compiling from source. [1] https://blog.golang.org/generate https://blog.golang.org/generate
    • eternalban 12y ago
      There are other options. This thread interested me enough to start sketching out a different approach. I don't see the point of the maintainers of the exoskeleton generating an unbounded set of permutations.