logoalt Hacker News

klibertpyesterday at 5:13 PM2 repliesview on HN

> They all have failed.

That's not true. Most have failed, but those who used the right tool for the job - a rich, static type system in a functional language - did succeed. It's just that such type systems are rare, and even if nominally a type system is good enough, the required boilerplate might be uneconomical to maintain. Scala and F# are probably the only two languages that are mainstream-adjacent, at least, and have type systems expressive enough that using them to track escaping is not an absolute hassle. And they're both tiny in terms of the number of users.

In the end, we did settle on APIs that hide the escaping process (prepared statements, innerText vs. innerHTML, etc.) just because it's a) good enough; and b) possible to implement more or less uniformly across the TIOBE Top 20. That's good, but if you happen to use a language that's powerful enough, you probably also should track the escaped/unescaped status in the type system - it can be a cheap, additional safety net.


Replies

friendzisyesterday at 7:49 PM

While all you said is essentially correct, I want to nitpick that things like prepared statements quite specifically separate instructions from data and innerText is designed to skip processing of instructions in the input. They are indeed solutions to the escaping problem, but they do not make the escaping better, they avoid escaping altogether by different design.

ikirisyesterday at 11:16 PM

You proved their point and you don't even realize it. Those aren't escaped inputs, they're segregated precisely because escaping an input channel is an unwinnable jr engineer trap.