Reusable and type-safe options for Go APIs

I find I don&#x27;t care for implementing the Options paradigm. More often then not, the things I&#x27;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.<p>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&#x27;t find myself creating these kinds of constructs. My most configurable things are usually server instances.<p>For those who do use the Options paradigm and find it useful, what are you creating?

I&#x27;ve been using Go as my preferred language for almost a decade now. Hackish &quot;clever&quot; solutions like these coming from designers of the language like Rob Pike and Dace Cheney simply indicate that the language is hitting its limits of expressivity and needs to start thinking hard about overloading which is the right solution to problems like this.

Once you accept that the golang type system can&#x27;t enforce everything your life will be easier.<p>Use rust or Haskell if you want a powerful type system that can do fancy things.<p>golang is great, but you have to accept that some things are runtime errors, and that&#x27;s fine, it keeps things simple. How often are options given conditionally anyways? Simple tests will cover this in most cases.

How is it not cleaner and simpler to just use something of a builder pattern?<p><pre><code> srv = NewServer(addr).WithTLS(crt,key).WithRateLimit(30).WithPool(10).Start() if srv.Err() { &#x2F;&#x2F; Handle }</code></pre>

The downside to this solution is that the concrete option types are exported. I believe it&#x27;s possible to return unexported types from exported functions, which would solve this, but that golint complains about that pattern.<p>Have you suggested this to the etcd maintainers?