This session explores the new Go plugin system, its implications, and how it may change the design and implementation of large software systems in Go.
Description
Go version 1.8 introduced tons of exiting and significant features including a new plugin system which let programmers create shared object library modules that can be bound dynamically at runtime. Prior to this, Go programmers have relied on out-of-process approaches such as OS exec calls, sockets, RPC/gRPC (and so on) to achieve code modularization. While these approaches work, most of them, however, were meant to be ends to a mean that was not supported in Go.
The introduction of the plugin system gives Go another vector of physical modularity (beside regular packages). Similar to other established languages, Go is now capable of loading and binding to exported variables and functions in shared object libraries at runtime. This opens the door for new ways of building and deploying applications in Go. For instance, it is conceivable that in the near future Go projects are be distributed, as not only source packages that must be recompiled, but also as shared objects binaries for dynamic binding at runtime.
In this session, we will explore the new Go plugin system and what it means for code modularity in Go. We will focus on design and implementation of programs that can scale features using the plugin system. Topics will include (not limited to):
Anatomy of shared objects
Understanding Go’s plugin
API Design with plugins
Creating modular apps with plugins
Deployment implications
Security implications
The new plugin system can potentially ease the Go community’s collective grip on the single-binary mantra. The first implementation of a plugin system in version 1.8 gives programmers a preview of what will be a prized feature in Go. I invite you to join this session to find out what how you can leverage plugins in your next projects.
This session explores the new Go plugin system, its implications, and how it may change the design and implementation of large software systems in Go.
Description
Go version 1.8 introduced tons of exiting and significant features including a new plugin system which let programmers create shared object library modules that can be bound dynamically at runtime. Prior to this, Go programmers have relied on out-of-process approaches such as OS exec calls, sockets, RPC/gRPC (and so on) to achieve code modularization. While these approaches work, most of them, however, were meant to be ends to a mean that was not supported in Go.
The introduction of the plugin system gives Go another vector of physical modularity (beside regular packages). Similar to other established languages, Go is now capable of loading and binding to exported variables and functions in shared object libraries at runtime. This opens the door for new ways of building and deploying applications in Go. For instance, it is conceivable that in the near future Go projects are be distributed, as not only source packages that must be recompiled, but also as shared objects binaries for dynamic binding at runtime.
In this session, we will explore the new Go plugin system and what it means for code modularity in Go. We will focus on design and implementation of programs that can scale features using the plugin system. Topics will include (not limited to):
The new plugin system can potentially ease the Go community’s collective grip on the single-binary mantra. The first implementation of a plugin system in version 1.8 gives programmers a preview of what will be a prized feature in Go. I invite you to join this session to find out what how you can leverage plugins in your next projects.