Getting parsers right will always be important, since they're often "on the front lines" exposed directly to untrusted input and thus the easiest code to manipu

Getting parsers right will always be important, since they're often "on the front lines" exposed directly to untrusted input and thus the easiest code to manipulate. That includes making sure they can't be made to crash, eat up unbounded amounts of memory, or return semantically invalid to the next layer of the program. But in most cases, it shouldn't require ensuring they can't be made to execute arbitrary code, because we should be writing them in languages that do not allow for such vulnerabilities. Over the years, the arguments against doing so are getting weaker as the costs of not doing so get bigger. Soon there will be no excuse.