[MrDarcy]

> It's a lot of boilerplate to create something that's not actually immutable

How is not actually immutable? How could cfg.opts.name be modified after New() returns?

> It also makes it harder to figure out which options are available

I find it easier, the go tooling helps a lot. For example, all the options are grouped together at https://pkg.go.dev/github.com/go-kit/log/level#Option

It's also easy to use "Find Usages" in my editor, and filter on return type.

[jen20]

It could be mutated by anything in the package that contains the type. The only thing Go can make truly immutable - as in a compiler error if you try - is a constant primitive.

Functional options have some niceties - largely their ability to evolve without breaking changes - but as the GP points out, completely break discoverability with intellisense. Having to do some dance with filtering usage to find the options available is just worse than a static config struct with zero values that are meaningful for anything not set.