[masklinn]

It's the tagline the author used on Twitter: https://twitter.com/justincormack/status/1153060402495991808 and seemed clearer than the actual title.

> perhaps the intended meaning of the title was "fuzzing shows that memory-unsafe languages are untenable", but that's certainly not the meaning of the current title

No, fuzzing makes these languages untenable because it provides a tool for automating memory unsafety issues. Without mature fuzzing tools, most of these issues can remain unfound, but fuzzing surfaces them — and their potential for exploitation — rather easily.

It's a bit of a "security by obscurity" thing, but I think there's a point to this view: fuzzing takes the existing crack / fault of memory unsafety[0] and blasts it open so wide you can get a truck through.

[nullc]

> fuzzing makes these languages untenable because it provides a tool for automating memory unsafety issues. Sans mature fuzzing tools, most of these issues can remain unfound,

<Pointy-haired Boss>Fuzzing is now forbidden in our offices. Next problem?</phb>

[snaky]

Jokes aside, Pointy-haired Boss ask why should we care about security issues from the business standpoint. Do we know any company went out of business due the security breach?

[jusob]

Yes, last month for example: https://healthitsecurity.com/news/amca-files-chapter-11-afte...

[gmueckl]

Not yet, but fines due to GDPR violations might have that effect in the near future. That only requires that a security hole leads to a massive data breach.

[dinglejungle]

Ah, I see. It would help if the article made that argument a bit more explicitly, as I totally missed that interpretation the first time through.