From reading the abstract, it sounds like this addresses precisely the topic of &quot;Worse is Better&quot; [1].<p>There are frequent misunderstandings of this essay -- the argument isn&#x27;t as coarse as &quot;crappy software wins&quot;, or &quot;release early and often&quot;.<p>The tradeoff is: do you want a simple interface (MIT style) or a simple implementation (NJ style)?  If you want a simple interface, you have to hide a bunch of complexity underneath.  If you want a simple implementation, you punt on some hard things and expose it to the user.<p>Despite its authorship, and marketing as a better C (which is the epitome of NJ style), Go is MIT style!  The concurrency model hides a lot of stuff under the covers: sync vs async syscalls, segmented stacks, etc.  And GC is probably the ultimate MIT-style feature, in that the interface is very simple (just pretend you have infinite memory), but implementations are tremendously complex -- basically each GC is unique and its own research project.<p>[1] <a href="https:&#x2F;&#x2F;www.jwz.org&#x2F;doc&#x2F;worse-is-better.html" rel="nofollow">https:&#x2F;&#x2F;www.jwz.org&#x2F;doc&#x2F;worse-is-better.html</a><p>EDIT: From paging through the slides, this seems to be basically the gist of the last half, but I don&#x27;t see that he mentioned &quot;Worse is Better&quot; or MIT vs NJ style...