> It's the only way to guarantee policies like no network, no file access, no unsafe code or FFI for a library before it even compiles.

It's not the only way. You can sandbox processes. I think sandboxing is the much more reasonable approach, because in the end of the day, there are still closed-source software products where you can't demand that the manufacturers use certain language safety features.

Sandboxing the process only works well when the malware requires more capabilities than the software itself.

So if your software needs to make HTTP requests and read the filesystem then the malware will be able to make HTTP requests and read the filesystem, which is enough for a ton of malware. Sure, maybe you can limit the directories it can access a bit and possibly some sort of network filtering, but it isn't a silver bullet.

Capability security in-language would make a huge difference, because the more granular you "sandbox" the less likely it is that the compromised component has the access it wants. For example if the HTTP client library is compromised maybe it can't access the filesystem so can't steal your cookies. Or maybe like in this case no permissions were needed at all and despite the process having enough capabilities for malware this malware can at worst return bad values and try to chain this to an exploit which is far more difficult than just running it itself.

I don’t even understand what a capability based language is, but presumably closed source software wouldn’t apply here? Is it common for closed source software to give the source code to customers to build?