plugins (late 2 0 1 2 , early 2 0 1 3 ), plugins over RPC were the only option since Go didn't support dynamic library loading. Today, Go supports the plugin standard library with a number of limitations. Since 2 0 1 2 , our plugin system has stabilized from tens of millions of users using it, and has many benefits we've come to value greatly.For example, we use this plugin system in Vault where dynamic library loading is not acceptable for security reasons. That is an extreme example, but we believe our library system has more upsides than downsides over dynamic library loading and since we've had it built and tested for years, we'll continue to use it.Shared libraries have one major advantage over our system which is much higher performance. In real world scenarios across our various tools, we've never required any more performance out of our plugin system and it has seen very high throughput, so this isn't a concern for us at the moment. https://github.com/hashicorp/go-plugin#what-about-shared-libraries
an application during execution, perhaps based on user-defined configuration, may be a useful building block in some designs. In particular, because applications and dynamically loaded functions can share data structures directly, plugins may enable very high- performance integration of separate parts. However, the plugin mechanism has many significant drawbacks that should be considered carefully during the design. For example: … . Ref: https://github.com/golang/go/issues/ 5 68 93 https://pkg.go.dev/plugin#hdr-Warnings
6 3 手 HashiCorp go-plugin GRPC README 見 `It uses the same de fi nition as gRPC, but go-plugin communicates with plugins in memory, not over RPC.` WASM Sandbox Secure by Default ⾒