This is widely joked about, there's even a Wikipedia article: https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law

"What Andy giveth, Bill taketh away"

I mostly disagree with the conclusion. GC can be very fast these days. Serialization to JSON does not really take much time. Granted, some scripting languages are terribly slow.

But the main problem seems to be a lack of a clear architecture in many systems. These systems have often accumulated so much technical debt that nobody understands why they are slow. Profiling and optimization might remove the worst offenders but usually don't improve the architecture.

Basically, in the software industry, we use the hardware gains to cover up our organizational deficits.

I don't think interpreted language or gc are inherently the issue you think they are.

You can write seven layers of lagging crap in c if you like.

Is json really that difficult to deal with?

JSON provides a lot of flexibility: it's human readable, it has explicitly-named/optional/variable-length fields, it provides nesting ... all of this comes with a cost:

- extra branching in the parsing code (the parser cannot predict anymore what the next field will be, they could be in any order)

- extra memory allocations, decreased memory locality (due to variable-length/optional fields, and also the tree-like structure).

So if your data consists in a single object composed of a timed-fixed set of little-endian integer fields, you're comparing the above costs to the cost of a single fread call* with no memory allocations.

* many other data formats provide similar flexibility, text-based ones (XML) and also binary-based ones (IFF, protobuf, ISOBMFF, etc.)

don't write it as such though, you must write the endianess-decoding code (which the optimizer should trash anyway on little-endian architectures - e.g LLVM does).