[sethammons]

I find I don't care for implementing the Options paradigm. More often then not, the things I've implemented have required parameters, and sometimes many of them. Mixing required and options often feels kludgy. I feel the Options method requires lots of documentation referencing, as opposed to more discoverable (via your editor) constructors. I tend to use explicit parameters or a struct with validators where every field is expected to be explicitly set.

This is not to say that using Options is wrong. Some things are highly customizable and having too many constructors would not be an appropriate solution. Worse would be a struct based config where you only set some fields some times. I just don't find myself creating these kinds of constructs. My most configurable things are usually server instances.

For those who do use the Options paradigm and find it useful, what are you creating?

[chimeracoder]

I have to say I agree. I came to Go from functional languages (primarily Lisp), so you'd think that the "Functional Options for Friendly APIs" pattern would appeal to me, but I've never seem an implementation that I've actually liked to use.

[hellcow]

This is a nice implementation from Dave Cheney: https://github.com/pkg/profile

[eternalban]

> More often then not, the things I've implemented have required parameters, and sometimes many of them.

The disconnect for OP here is that generalized systemic approach (think e.g. Java Beans for one of the earliest attempts) is necessary for the container-component architectures [but arguably un-necessary for application specific approaches (which has informed your experience.)]

Go, imho, is a poor fit for the container-component paradigm. It certainly can meet the initial requirements (context + options) but the lack of first class metadata facilities will limit the possibilities (sans code generation) in that architectural space.

[pre-emptive p.s.: "container" here /does not/ mean process level composition ala Docker, etc.]

[jopsen]

I personally prefer something like:

> type Options struct { ... }

> func myMethod(arg1 string, options Options) {...}

Then have people pass in "Options{}" and let the zero-values imply default.

But most of the time, if you are making things complex, you're missing the whole point of golang. The innovation in golang is it's simplicity, if you miss that, then you might as well code C++ (which have more features for these kinds of things).