> When you ADD two registers, you really are making two reads in the register file, which really is a piece of physical hardware, and those reads really do go t

> When you ADD two registers, you really are making two reads in the register file, which really is a piece of physical hardware, and those reads really do go to a physical adder and get written back to the real, physical register file You've elided a pile of abstraction here too, like what it actually means to "read" and "write" the physical register file. Additionally, CPUs do a ton of microcoding of operations, so simple instructions like a 2-register ADD may correspond to the "obvious" thing, but more complicated ones will go through more hardware/do more things. The gulf of abstraction between the physics and any programming language is vastly larger than differences between programming languages, so it's weird that all of the hardware and operating system and C+GC is the right abstraction, but "tiny" extensions, say, like hardware and operating system and C+GC+generics^ is not right. ^ (Any of the common ways to implement them.) > In contrast, adding some lazy FP callback into your latest node.js framework on DOM objects might be doing something, somewhere, but who on earth really knows? This is the false comparison! Even Go can conceal arbitrarily complicated operations behind function calls. I can make a Go API that takes closures to execute later too. (There's even core language support built on this idea, `defer`, that behaves in a way that's resistant to the straightforward (RAII-like) implementation.) If we're going to be talking about things at the instruction-level, you can definitely complain about the dynamism of Ruby forcing even simple + to be (quite) a few more instructions, but you need to consistently look at either the micro-scale or the macro-scale, or explicitly connect the two. If you were doing DOM manipulations in Go, I'm sure, say, listening for some events (like a "lazy FP callback" might be) would be at least a similar order of magnitude in terms of non-obviousness to the JS version. It's fair that different language/ecosystems may encourage/lend themselves towards different coding styles, but this is most evident with apples-to-apples comparisons.