Vladimir Vivien
Sep 23, 2018 · 1 min read

Benjamin Maisano thank for the feedback. Yes, it’s been a while since I have written about this subject. The new module concept introduced in version 1.11 of Go is all about source code modularity for the purpose of dependency management and source reproducibility at buildtime.

The level of modularity discussed in this write up is about Go plugins. Plugins are more concerned about runtime module sharing for code reuse. I have not given much thought about the overlaps of the two concepts, but I suspect they are related even if at a shallow level.

Now back to your main question about Go plugins. I consider plugins as runtime extensibility mechanism. Meaning, that plugins should be used as way to extend a product or a tool at runtime where you may want your users/developers to have very defined extension points, that can hook to a running code, without being concerned with internal details.

Injecting common types in a microservice architecture would probably work better using traditional Go package construct for buildtime code sharing. In a monolithic repo where the code already lives together, this would be a better way of code reuse than using Go plugins.

Hope this helps. Thanks again for reaching out!

    Vladimir Vivien

    Written by

    Software Eng • Go Programming • Kubernetes • Author http://golang.fyi