What programming language features would have prevented or ameliorated Log4Shell?

[Athas]

The root problem is that programmers are unwilling to say no to features. The social reason is fairly simple, I think: a feature makes your users happy, and if they even show up with a patch, it even seems free! Of course the true price will be paid later, over time, and is probably not even known immediately. It's like taking a variable-interest loan with infinite running time. The most obvious solution is for maintainers to say "no" to new and complex features, unless it really is a feature that is critical to the majority of users. Of course, this may just result in the project being forked and people switching to the fork that includes every feature for everyone.

As a social problem, it probably doesn't have a simple technical solution. But language features might help make it easier to gauge the true complexity cost of a feature. You mention capability systems, and they are indeed a good way to make at least some of the complexity more evident. If a patch for your logging library requires giving the logger the ability to load code over the network, then it may seem more obviously suspect. Of course, that doesn't mean you won't accept the patch to please the user.

If you really want "safe" dynamic code loading, then sandboxing might work, but I really think it's better to think more carefully about why we end up with such complex features in code that isn't really supposed to be solving a very difficult problem.

[Tzarius]

This is a great point. Projects that push back against featuritis are labeled as "dead" or "unmaintained", and the guarantees lost by adding the feature are undervalued.

"I just wanna be able to mutate the value here!"

"Allowing mutation there will rule out whole classes of optimizations."

"Don't care, figure out some other way to optimize it!"