Thanks for the illuminating link.<p>Nevertheless, I unfortunately do not see an easy solution in the near future that avoids C&#x2F;C++ much as I would love to ditch them. Let us leave aside the question of legacy code and focus on future systems projects.<p>General issue:
C and C++ have an advantage in the sense that we understand their many problems well due to their long history, and they have formal specs that are far more carefully written than most others, where documentation is spotty and formal specs are often lacking. 
Example: I have not studied Rust closely, but it seems to me that there are sections that essentially must be placed under &quot;unsafe&quot; for performance or low level access. The oft-repeated claim is that it minimizes the surface, since it localizes the unsafe sections. I have not seen any hard, formal guarantees in either the spec or implementation as to what is precisely meant by this. I am very interested to know how I can reason that the unsafe section has zero side effects outside of it. Such a statement in general must be false, since the unsafe block clearly communicates with the rest of the program, else it is dead code. And if the interface is sandboxed (an imperfect solution), then it implies some kind of performance penalty across the barrier, implying additional cognitive load for a developer since he&#x2F;she has to reason about the possible performance impacts for such things, among others like array bounds checks. Lastly, if the guarantee regarding the extent of the &quot;unsafe&quot; block is as complicated as I suspect it to be, the load is increased further. Of course, the load comment is really relevant to Rust vs C and not Rust vs C++.<p>Specifics:
1. Go - garbage collector, large runtime&#x2F;binary sizes, portability issues (AIX: <a href="https:&#x2F;&#x2F;groups.google.com&#x2F;forum&#x2F;#!topic&#x2F;golang-nuts&#x2F;IBi9wqn__FY" rel="nofollow">https:&#x2F;&#x2F;groups.google.com&#x2F;forum&#x2F;#!topic&#x2F;golang-nuts&#x2F;IBi9wqn_...</a>).
2. Rust - too new, general points above.
3. D - lacks the same energy as the above projects, so likely fares worse than the above. Furthermore, due to its closer ties to C++, its rather incremental nature resulted in a significant loss when C++11&#x2F;C++14 came around.
4. Others - too many to list, focused on above due to their frequency on Hacker News.