&gt; I would also say that although I might lose some performance advantages with a functional approach, the improvement to system comprehension means better human optimization of distributed multi-core contexts.<p>You don&#x27;t even need to bring in parallelism for functional approaches to gain in performance. Here&#x27;s an example (in Rust) of how you&#x27;d implement collecting an iterator into a vector using the &quot;machine simple&quot; approach:<p><pre><code>    let mut array = vec![];
    for element in some_iterator {
        array.push(element);
    }
</code></pre>
Now for the functional, less &quot;machine simple&quot; approach:<p><pre><code>    let array = some_iterator.collect();
</code></pre>
Which is faster? Without knowing the details of the compiler, you might think the former is faster, because there are fewer function calls and less indirection. But this is wrong, as the compiler will trivially inline &quot;collect&quot; for you and eliminate any indirection.<p>In fact, it turns out that the second approach is often <i>significantly</i> faster, because the standard library contains the equivalent of:<p><pre><code>    let mut array = Vec::with_capacity(some_iterator.size_hint());
    for element in some_iterator {
        array.push(element);
    }
</code></pre>
That is, it uses the size_hint() method to avoid reallocating during the collection operation, reducing the number of memory allocation and array copy operations to O(1) instead of O(log n).<p>What are the chances that you&#x27;d do this important optimization manually? Not high: it adds noise, it&#x27;s esoteric, and it&#x27;s easy to forget. But if you use the functional idiom, you benefit from the optimized approach every time. <i>That</i> is the true benefit of abstraction, which is really the key point here. &quot;Machine simple&quot; and &quot;fast&quot; are frequently in <i>opposition</i>, and too often people think that the former implies the latter.