Hi, I enjoyed your article.<p>You have some good points about tiny types, but if you read through the code in the Go standard library, you won&#x27;t find this style applied in very many cases. Typically, only if one wishes to attach a method to a built-in.<p>As another poster rightly pointed out, it complicates the documentation quite a bit, and I think a lot of Go programmers would consider it pointless abstraction.<p><pre><code>    &#x2F;&#x2F; NewBox creates a new Box. It returns an error if length
    &#x2F;&#x2F; or width are less than or equal to zero.
    func NewBox(length, width float64) (Box, error) {
        ...
    }
</code></pre>
Consider the simplicitly of NewBox. We may omit a Length and Width type, and any validation of these by stating the expectations of the inputs in the documentation. So, the API is dramatically simpler. The expectation is that the programmer will not pass invalid arguments to NewBox, by way of common sense or reading the documentation. Programmers who pass in positive numeric literals may even opt to ignore the error returned, since the documentation states the the only reason an error would be returned is if the input parameters were &lt;=0.<p>Go puts a big emphasis on documentation, and this often compensates for lack of power in its type system.