&gt; Not having that possibility enforces you to actually design an elegant API<p>Yes, of course, the forced elegance of MarshalIndent next to Marshal — being able to indent in Marshal would be graceless, of CreateHeader alongside Create in case you wish to specify more than just the file name, of asn1.Unmarshal and its friend asn1.UnmarshalWithParams, so much more dignified than Unmarshal optionally taking params is it not?<p>You&#x27;d have to be blind not to see the refinement of DialHTTP to connect to an RPC server, unless you want to connect to a path which isn&#x27;t &#x2F; then DialHTTPPath has that undefinable quality of an excellent API, you definitely wouldn&#x27;t want DialHTTP to just have a default path that would be tasteless.<p>And it&#x27;s really quite obvious to have ToUpper and ToUpperSpecial, can you imagine how unpolished an optional case parameter to ToUpper would look?<p>Or Split taking an optional number of substrings? How gauche, lucky us the designers of the API were forced to add the soigné SplitN to which you can explicitly pass a negative number to get all substrings.<p>Really there are so many examples of the lack of optional parameters forcing the design of an outright dandyish API. Just look at WIN32, saved from the dreaded &quot;lots of arguments&quot; by C not having default parameters, not a function in there using <i>that</i> to hide the mess no sir, not in a million years would a language with default parameters have achieved the summit, the peak, the pinnacle of delight that are CreateWindowEx or RegQueryValueEx.<p>And naturally optional anything means you will build an inelegant API one day and have lost all chance to elegant API, which is why Go requires all structure fields to be explicitly filled.