"parity" is the keyword here. Most of the time, the problem doesn't come from sloppy execution, but ever widening scope of the software.
For example, my own "Almost C" compiler[1] is 1137 lines of code. 1137! Can it ever reach "parity" with gcc or even tcc? No! That's specifically not the goal.
Do I benefit strongly for having a otherworldly simpler toolchain? hell yeah.
The key is scope, as always. Established projects have, by virtue of being community projects, too wide a scope.
Agreed, parity is a strong constraint. Since the premise under discussion was “production” environments where some kind of parity is presumably required, I think it’s a reasonable assumption. If there is no baseline and it’s not a production situation where parity is needed, then yeah scope can and should be constrained as much as possible. I like the phrase “otherworldly simple”, I might borrow that!
I don't think that people deciding what goes in "production" are immune to scope inflation. Thinking that we need parity with another software without realizing the cost in terms of complexity of that parity requirement is, I think, a big driver of complexity.
For example, my own "Almost C" compiler[1] is 1137 lines of code. 1137! Can it ever reach "parity" with gcc or even tcc? No! That's specifically not the goal.
Do I benefit strongly for having a otherworldly simpler toolchain? hell yeah.
The key is scope, as always. Established projects have, by virtue of being community projects, too wide a scope.
[1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/co...