That being said, change is inevitable, so this desire for maintainability can't prevent all change.
It's a shame they couldn't find a way to balance these things.
If we accept this as the core concern:
> Having worked on codebase like that they are my worst nightmare, because there is a constant churn of rewriting parts from language A to language B
Then he has no need to fear, nothing in the foreseeable would have affected him in any way.
He didn't like that he didn't have control over what other people elsewhere were doing. But there was an extremely generous balance offered him, to be utterly unaffected in any way. And that wasn't good enough for him.
Co-incidentally, I was just listening to the radio, where a former BP strategy employee was pinning the failure of BP's "Beyond Petroleum" strategy squarely on the difficulty of a company that is built to do activity X pivoting to also do (competing) activity Y. The recommended solution there was to spin off a new entity focused entirely on Y. It's hard not to draw a parallel.
>In a similar vein, there's no inherent reason to use a calculator over doing calculations on paper.
Improved speed and reduced mental overhead are the main reasons people use calculators, not accuracy. This is because you can use any tool such as a calculator (or programming language) incorrectly.
I used to hear that the difficulty of relating CPU instructions to lines of C++ was the reason it wasn't suitable for the kernel. Now, all that has gone out the window (as Rust is definitely no simpler than C++), and they're making changes to the Rust language to suit the kernel application (as opposed to using something tried and true). It's a bad idea, but I expect it to be carried out to the point of absurdity.