As others have said here, it just feels really un-Go-like (although I'm not a Go user so maybe I don't have the right intuition). Do you really need such a high

As others have said here, it just feels really un-Go-like (although I'm not a Go user so maybe I don't have the right intuition). Do you really need such a high-level, abstract mechanism just to be able to turn on trace logging? The clunky "big struct of options" approach seems much more idiomatic, and doesn't have any immediately obvious downsides. (That blog post you linked says it's "unsatisfactory"; I guess there's more detail on that elsewhere.) For scoped logging, the obvious approach would just be to add a "setVerbosity" method to your object. You can try to do it in the most general way possible, sure; but that feels similar to building lots of generic data structures and other abstractions, which is something that Go intentionally resisted for a long time (on the basis of keeping things simple and concrete, rather than building ivory towers of abstractions). Anyway, the "Functional Options Are Slow" article reads like a post-hoc justification written by somebody who never liked functional options in the first place anyway -- i.e., the stuff in the final section. The real argument is "I think functional options are a bad idea for style and usability, but if that doesn't convince you, you can also look at the raw performance numbers, and it turns out it's really expensive too." Which I think is a good argument!