Go 1.18 makes reusable code and local modules explicit

Working on two Go modules together should not require pretending that a local directory is the published dependency every consumer ought to use. Reusing an algorithm should not require losing the relationship between its input and output types. Go 1.18 addresses both problems, with different mechanisms and different consequences for the packages that use them.

The 15 March release announcement presents generics alongside native fuzzing and workspace mode. It describes multi-module development as the most common module challenge in the project's 2021 survey. That context matters. Much of this release concerns making recurring work expressible through the language or its standard tools, without requiring each project to maintain its own substitute.

I value Go's readability more than the size of its feature list. This release is appealing where a declaration or a tool command replaces a convention that readers otherwise have to reconstruct. The benefit depends on keeping the new mechanism close to the specific problem that requires it.

Reuse without erasing type relationships

Ian Lance Taylor's 2019 explanation of generics starts with a slice-reversal algorithm. Its logic is unchanged when the element type changes. Ordinary interfaces can express methods used by an algorithm, but requiring adapters for each slice type moves some of the duplication elsewhere. Reflection or code generation introduces other maintenance costs.

The distinction is between sharing behavior and preserving relationships among concrete types. A reusable transformation should be able to say that its input contains one element type and that its output contains another. A container should retain the type of the values placed in it. Those relationships provide information to callers and to the compiler.

Go's accepted type parameters proposal places type parameters in square brackets after a function or type name. Each parameter has an interface constraint. Operations in the generic body must be valid for all types admitted by that constraint. Common function calls can omit type arguments when inference determines them from ordinary arguments.

That last convenience does not remove the constraint from the design. A caller may see an ordinary-looking function invocation, while the declaration states the relationship that makes it safe. Reviewing generic code therefore starts with the declaration and the operations in the body. A broad constraint makes the function available to more callers but permits fewer operations. Restricting the constraint needs a reason in the algorithm.

This gives library authors a way to separate an element type from the mechanics of a data structure. It also creates another place where unnecessary abstraction can accumulate. A parameter that exists only to accommodate one imagined future caller makes the current declaration harder to read without establishing a present benefit.

My preference is to introduce generics when the shared algorithm is already clear. Repeated code can reveal which parts are stable and which parts encode different requirements. Combining the latter behind a type parameter does not resolve their semantic differences.

Compatibility includes the limits of the implementation

The Go 1.18 release notes maintain the Go 1 compatibility promise while explaining that generic code lacks the production experience of older language constructs. They also identify experimental generic packages under golang.org/x/exp. Those packages do not acquire the standard library's compatibility guarantee merely because their language features are released.

The separation is useful for dependency decisions. Choosing the released compiler and choosing an experimental helper package are independent commitments. A project can use type parameters without treating every accompanying experiment as a stable dependency. Conversely, the existence of an experimental helper gives the community somewhere to develop an API before its long-term obligations become harder to change.

The December first beta announcement had already described certain recursive generic cases as postponed. Today's release announcement likewise says more complicated use cases will receive additional support in subsequent releases. Neither statement promises that arbitrary generic designs are supported today. The relevant implementation is the released compiler, with the documented language rules and limitations available now.

For maintainers, this is a reason to describe a generic package's actual requirements. A declaration that relies on a narrow supported pattern is easier to assess than an assertion that a language now has generics. The feature name alone says little about the complexity a particular library asks its users to understand.

Fuzzing gives a behavioral property more inputs

Native fuzzing addresses a different problem. The 2021 fuzzing announcement explains how input mutation can discover code paths and edge cases missed by existing examples. Its parsing example checks whether encoding a parsed query and parsing it again preserves the result. That is a relationship the test can check for many generated inputs.

A generic signature cannot establish such a property. It can constrain types and permitted operations, but an algorithm can satisfy those rules and still return the wrong answer. Fuzzing is useful when the developer can state a behavioral invariant that remains meaningful as inputs change.

The testing implementation in the Go 1.18 tag documents how seed inputs enter this process. Calls to F.Add contribute values, and files under testdata/fuzz provide persisted corpus entries. A normal test run executes the seed corpus. Explicit fuzzing generates additional inputs against the target function.

That relationship makes a discovered failure useful beyond the exploratory run that found it. A concrete input can become part of the package's regression tests. The property remains the important authored part of the test. Generating inputs cannot compensate for a target that accepts incorrect behavior or fails to check an observable result.

Resource use is part of the mechanism. The earlier announcement warns about parallel workers and memory consumption, while the release notes warn that the fuzz cache has no built-in size limit. An indefinite run is not an appropriate default for every development machine or CI job. Selecting an explicit duration and worker count expresses the budget for that exploration without changing the property being checked.

Workspaces describe a local set of main modules

The Go 1.18 command documentation describes a workspace through a go.work file. Its use directives name directories containing go.mod files. The command treats those modules as roots for builds and related module operations. The directory paths describe a local development arrangement.

For example, a workspace containing two existing modules can use this file. Both paths are relative to the directory containing go.work.

go 1.18

use (
    ./service
    ./library
)

Each listed directory must contain its own module. The file does not combine them into one published module, and a use directive does not declare a new module path. Keeping that distinction clear helps explain why a successful workspace build is evidence about a particular local arrangement.

An author changing both modules can compile against the local library while developing the service. A downstream consumer still depends on the module requirements available to that consumer. Publishing the library and updating the service's requirements remain meaningful actions. Workspace success should not be interpreted as proof that the independently consumed modules have all their required changes available.

The command documentation also specifies workspace replacements. A replacement in go.work takes precedence over replacements in individual go.mod files and can resolve conflicting local arrangements. This is useful precisely because the workspace has authority over the combined build. That authority should be visible when interpreting a result.

The active workspace can be inspected directly. The command below reports the file used by the current environment.

go env GOWORK

The command reports which workspace file is in use. When two environments produce different behavior, that is a concrete configuration fact to compare. The relevant distinction may be the selected set of local main modules, not a mysterious difference in module downloading.

Synchronization is a separate operation

Go work sync computes the workspace build list through minimal version selection and updates dependencies in the workspace modules to that list. The command documentation explains that this can upgrade individual module requirements to the versions selected for the combined workspace. Merely listing directories and synchronizing their requirements therefore express different intentions.

This distinction deserves attention in development scripts. A script that establishes a local workspace describes where source is read. A synchronization command can also change module dependency declarations. Combining those actions invisibly makes it harder to understand why a go.mod file changed during otherwise local work.

I see the strongest part of this release in those explicit boundaries. Type parameters state what an algorithm requires of its types. Fuzz targets state behavior that generated inputs can challenge. Workspace files state which local modules participate in a build. Their use remains understandable when each declaration answers its own question and the resulting code preserves the requirements of independent consumers.