&gt; You need a great inliner. You want common subexpression elimination (CSE), constant propagation and folding, strength reduction, and an excellent loop optimizer. These days, you probably want to use static single assignment form (SSA), and some unique SSA optimizations like global value numbering (although you need to be careful about working set and compiler throughput when using SSA everywhere)…I hate to say it, but doing great at all of these things is &quot;table stakes.&quot;<p>I&#x27;m not sure. It depends on the audience you&#x27;re aiming for. Go has done very well with a compiler that essentially performs no compiler optimizations (by modern standards; certainly it doesn&#x27;t do most of the above) by positioning itself appropriately.<p>&gt; For example, there are ways to write the earlier loop that can easily &quot;trick&quot; the more basic techniques discussed earlier:<p>Yeah, bounds check elimination ends up nightmarish quickly. I think I prefer an approach that fixes the problem at its source, by just encouraging programmers to stop using for loops (which are bad for non-performance-related reasons as well). Note that all of the examples given use for loops; if they were rewritten using iterators, there wouldn&#x27;t be a problem. C# has iterators, so the machinery is there; they just need to make it more painful to use a for loop than the iterator alternative. :)<p>&gt; Imagine you have a diamond. Library A exports a List&lt;T&gt; type, and libraries B and C both instantiate List&lt;int&gt;. A program D then consumes both B and C and maybe even passes List&lt;T&gt; objects returned from one to the other. How do we ensure that the versions of List&lt;int&gt; are compatible?<p>I don&#x27;t understand why this is a problem. Both separately compiled implementations of List&lt;int&gt; should monomorphize to bit-identical runtime value representations. Does the problem have to do with quirks of the compiler&#x27;s RTTI implementation (e.g. making sure &quot;foo instanceof List&lt;int&gt;&quot; in package A works even if &quot;foo&quot; came from package B)?<p>&gt;  First, Go generates the interface tables on the fly, because interfaces are duck typed.<p>Does it really? That&#x27;s interesting and seems extremely inefficient. I would have assumed that the Golang compiler would just statically determine the set of vtables that need to be used by the program and write them up front into rodata. Am I missing something?