3 ms·

I mostly agree with you but take the opposite position: attacking memory safety bugs has been so successful that we should use the same pattern on other large c

I mostly agree with you but take the opposite position: attacking memory safety bugs has been so successful that we should use the same pattern on other large classes of bugs. It's absolutely possible to write a reasonably usable language that makes injection/escaping/pollution/datatype confusion errors nearly impossible, but it would involve language support and rewriting most libraries--just like memory safety did. Unfortunately we are moving in the opposite direction (I'm still angry about javascript backticks, a feature seemingly designed solely to allow the porting of php-style sql injection errors)

0xbadcafebee 2y ago
Take that to its logical end: a language designed with high-level functions to automate all possible work that, if left to a human to craft, would expose security vulnerabilities. You know what you have there? A new method for developing software. If we just switch languages every time we have another class of vuln that we want to eliminate, it will take us 1,000 years to get them all. Or we could just get them all today by fundamentally rethinking how we write software. The problem isn't software. The problem is humans writing software. There are bugs because we are using a highly fallible process to create software. If we want to eliminate the bugs, we have to change how the software is created.