[Solved]: Why do we have to trade abstraction for speed?

Debunking some myths

1. There is no such thing as a fast langauge. A language can generally produce fast code, but different languages will excel on different benchmarks. We can rank languages on a particular set of flawed benchmarks, but cannot rank languages in a vacuum.
2. C code tends to be faster because people who need every inch of performance use C. A statistic that C is faster “by a factor of 10” might be inaccurate, because it might be that the people using Python just don’t care as much about speed and didn’t write optimal Python code. We see this in particular with languages like Haskell. If you try really hard, you can write Haskell that performs on par with C. But most people don’t need that performance, so we have a bunch of flawed comparisons.
3. Sometimes, it is unsafety, not abstraction, that makes C fast. Its lack of array-bounds and null-pointer checks save time, and have been the cause of numerous security holes throughout the years.
4. Languages aren’t fast, implementations are fast. Many abstract languages start slow, because speed is not their goal, but get faster as more and more optimizations are added.

The abstraction vs speed tradeoff is perhaps inaccurate. I would suggest a better comparison:

Simplicity, speed, abstraction: Choose two.

If we’re running identical algorithms in different languages, the question of speed comes down to the problem of “How much stuff do we need to do at runtime to make this work?” In a highly abstract language that is simple, such as Python or JavaScript, because we don’t know about the representation of data until runtime, there end up being lots of pointer de-referencing and dynamic checks happening at runtime, which are slow. Likewise, there are a lot of checks that need to be done to ensure that you don’t wreck your computer. When you call a function in python, it needs to make sure that the object you’re calling actually is a function, since otherwise you could end up executing random code that does terrible things. Finally, most abstract languages have overhead from garbage collection. Most programmers have agreed that having to track the lifetimes of dynamically allocated memory is a pain, and they’d rather have a garbage collector do it for them at run time. This takes time, that a C program doesn’t need to spend on GC.

Abstract Doesn’t mean slow

However, there are languages which are both abstract and fast. The most dominant in this era is Rust. By introducing a borrow checker and a sophisticated type system, it allows for abstract code, and uses compile-time information to reduce the amount of work that we need to do at runtime (i.e. garbage collection). Any statically typed language saves us time by reducing the number of runtime checks, and introduces complexity by requiring us to please a typechecker at compile-time. Similarly, if we have a language that encodes whether a value can be null into its type system, we can save time with compile time null-pointer checks.