[kevingadd]

In general the groups doing standardization for browser APIs and runtimes don't seem to care much about whether web applications are compromised, only whether the browser or host platform are compromised. It's reasonable for the latter two to be priorities, but when we're talking about huge gmail-tier applications running unsafe C in a sandbox that have access to All Your Important Data, we're going to massively regret letting type safety and other features slide.

[otabdeveloper1]

> ...we're going to massively regret letting type safety and other features slide.

PHP is memory safe, and yet is a larger source of data breaches and security bugs than C by (rough guess) an order of magnitude.

C is not the bogeyman you're looking for.

[ComputerGuru]

PHP may be memory safe but the shitload of poorly written C extensions enabled by default on all hosts that shipped with the distribution from 1995 to 2010 sure as hell weren't.

[otabdeveloper1]

C extensions wasn't the part of PHP that broke the amateur Internet, SQL injections were.

[TomMarius]

Using the WASM GC part instead of lieanr memory will solve that, right? I know it's not a possibility for all programs, but overall, it'll help?

[pjmlp]

Not at all, because a large majority of applications being ported to WASM are written in C and C++, with all security caveats it entails.

Garbage Collected implementations of C and C++ do exist, and only thing that their GC fixes is use after free.