That&#x27;s not a fair characterization of Swift&#x27;s runtime. Swift is similar to C++ in that it compiles down a lot of stuff so it doesn&#x27;t need to make runtime decisions.<p>Swift could theoretically be as fast or faster than C&#x2F;C++, but C&#x2F;C++ have decades compiler optimizations that are going to be hard to beat. I say Swift has the potential to be faster because of the pointer aliasing problems of C&#x2F;C++, which Swift can potentially optimize (like why Fortran still can beat C).<p>But your question about runtimes and performance are kind of a red herring. High performance means utilizing the underlying hardware well. A lot of the popular modern languages were designed for convenience over speed and were designed in an era of ever-increasing single processor CPU speeds. Very few languages map to how hardware actually works so they give up speed. Few mainstream languages automatically vectorize _well_ and _reliably_ to automatically exploit SIMD (C&#x2F;C++ don&#x27;t really do this...we generally have to write the intrinsics ourselves if we care). Few mainstream languages do a good job exploiting the multiple cores&#x2F;CPUs available to us  (don&#x27;t say threads...they are pretty poor. This is one interesting feature of Go). Cache locality is now extremely important to high performance and most languages don&#x27;t let us really control this. (C&#x2F;C++ give us some say on our memory layouts.)