Honestly it feels more like they make a lot of 40% solutions.

Well, as others have said: Hitting exactly 80% is pretty much impossible. And we've established that hitting more than 80% produces languages that are often bad, in some way or another.

So, logically it follows: aim for less than 80%. You can always add things; you can't take things away.

> And we've established that hitting more than 80% produces languages that are often bad

No we haven't; we've established (for very dubious values of "established") that aiming for more than 80% is frequently not worth the trouble.

Sometimes by aiming for less than 40% you add the _wrong_ thing, which you need to take away before you can add the right thing.

I've noticed this as well. It also attracts a lot of criticism. People are really insistent that a language should be perfect in exactly one area and terrible in others. They tend to support this kind of thinking with arguments about how you should pick the right tool for the application, as though most applications only care about one criteria or another (and need a language that trades everything for that one criteria).

That said, I think Rust does an impressive job at squeezing efficiency out of these tradeoffs. Sure, it trades off some developer productivity for extreme performance and safety, but its developer productivity story is still markedly better than other systems languages (and probably on par with some of the more cumbersome managed languages). Similarly, the tooling story is pretty great while every other systems language has pretty awful tooling (especially build systems). Moreover, Rust is getting better at a remarkable pace. I don't think it will ever close some of these gaps, but I think it will get close enough to pose a real threat.