"JSON-over-HTTP for RPC is lazy, inefficient in machine time and engineering effort, and trivially obsolete in a world where Protocol Buffers/gRPC or Thrift and their ilk are so mature."
Laziness is a virtue in our profession :) huge "citation required" on it being more efficient in engineering effort and most importantly it's ubiquitous and interoperable with any language without having to rely on grpc or thrift implementation and tools for that language/platform.
Re machine time efficiency - to the extent I understood what she was actually complaining about simply none of those issues are attributable to json-over-http being used.
On the digression of efficiency... treating efficiency as something you solve by throwing more machine resources at is causing recognizable problems today.
And the calculus of cost doesn't even always work out the same.
That's a prime example of survivorship bias, projects that spent their runway optimizing for machine resources are not around to have their problems recognized.
I had more than one project where people were cheaper than machines, and going tight on budgets for machine resources led to the project surviving instead of dying.
Hell, a big example of that is Stack Overflow, which runs a very busy site on much less hw than they would have needed otherwise, just by taking high level optimization questions up front.
I can spot, however, kernel-mode HTTP servers (including customized ones), and heavy use of pretty advanced stack with good optimization capabilities. The choices of the stack do make a big impact, something that they have mentioned several times, with the summary of "paying Microsoft licenses paid back very well compared to using popular open-source stacks"
Remember, Performance is also a feature. Both a non-functional one (to reduce your costs) or functional one (to have happier users).
Laziness is a virtue in our profession :) huge "citation required" on it being more efficient in engineering effort and most importantly it's ubiquitous and interoperable with any language without having to rely on grpc or thrift implementation and tools for that language/platform.
Re machine time efficiency - to the extent I understood what she was actually complaining about simply none of those issues are attributable to json-over-http being used.