I'd say that this prediction is describing current developments quite well. Newer programming languages (Go, Rust) and development tools are making the "software as lean independent components" vision more relevant than it ever was.
Performance comes from optimizing the usage of state against hardware, modularity comes from code satisfying the properties of composition which is best left stateless (and high levels of modularity must come from abstraction and conventional practice, incurring further debts on the programmer and machine.)
It's a tension that I haven't seen fully resolved but I'm very very very open to being wrong. Many languages seem to be experimenting in this space with some preference for one side of the equation for another.
We know how this works, at least in broad theoretical terms. Zero-cost abstractions are quite feasible within a self-contained module/component, but their scope is ultimately limited by ease of building and deployment. Nevertheless the performance impact of having to support high levels of abstraction across modules/components is quite reasonable, even if not literally "zero" cost.
Some have noted that JIT systems perform many of the same things as supercompilation, and it seems reasonable to consider that JIT is part of the equation for optimising performance when systems are pushed to production. We've been doing that for decades now, with increasing sophistication in the details. Profile driven, multiple stages of specialisation and optimisation.
Not quite to the levels of proof systems (and therefore supercompilation as envisioned) yet - there's plenty of room to get better at it - and we need to go there if we want those "zero cost abstractions" across modules that aren't designed for it, often with significant impedance mismatches.
* industry has either no interest or capacity in quality
* software flaws may cause severe harm but will play no role for the majority of the industry. it is a gamble just like vc business.
* pace of change/inonnovation will actually add even more harm
* excellence in the field will decrease because the baseline compexity is already too high, people will specialize probably in ML/AI/fin.
We could use a lot more of it in software.
Nothing can fix unnecessary complexity. It will continue to affect every tool used to maintain it.
What I never predicted was the sheer enormity of the useless cruft the community would build around it. I used to contribute to some of the React community places (particularly irc), and in the early days the discussion there was super interesting. Now it's just endless waves of "I'm building X and having Y problem with dependency Z" where Z is something I've never used because it looks shit, Y is something I haven't encountered in 3 years, and X is something I could build in my sleep with just plain old React.
I've always wondered if Java devs feel the same, or if they're happy drowning in whatever crap is in their ecosystem? Like, do they all love Java but hate every single code base they have to work on? Or is that a uniquely JS problem?