I think what zig really needs is something like the rust Axum ecosystem for web backend development. I would never be able to make a zig case at work without those sort of frameworks. People would say why zig without web related packages when you also have GOlang.
I'd say for the vast majority of use cases, it is.
Pluggable allocators + good test coverage make it trivial to catch a lot of the more common memory issues and exhaustive switches are quite robust (though it can be tricky when the branches vary according to the target platform).
Also, it is far easier to code in an exploratory, iterative fashion in Zig than it is in Rust.
Overall, I think with Zig and Go you can cover a lot of programming use cases. In fact, I find Go to be pretty damn fast out-of-the-box and in a lot of real world scenarios can match Zig/Rust (production builds). All three have room for fine tuning (at the expense of readability), though of course the ceiling is much higher in Zig and Rust.
Not to mention, Rust won't protect you from logic issues, you can definitely do the wrong thing correctly.
WebAssembly sandboxes apparently are going to sort out all security issues in modern computing.
For example, if you corrupt a program that's allowed to use web sockets, you'll be able to port scan the user's local network.
That's why traditional operating systems have processes that can't access each others memory. WASM instances don't have this sort of "internal isolation", anything running in the same instance can access all memory in that instance, memory safe language or not.
Again, language-level safety doesn't matter here. It makes a lot of sense to write the sandbox itself in Rust, but it must not matter whether code running inside the sandbox is written in Rust. If that would be required, the sandbox has already failed.
It very well can:
For example, let's assume you have a graphics editor running in the browser that stores files in the cloud. If it uses a vulnerable C library to decode image data, an attacker might be able to play havoc with your files despite the sandbox never technically having been breached.
This can be mitigated by either using a safe language, or having the decoder run in an isolated wasm instance. Either way, you have to design your application with these considerations in mind and can't just take arbitrary, potentially vulnerable applications, compile them to wasm and be done with it.
Apart from that it would be quite a feat to use internal memory corruption for anything useful in WASM, because both the code and callstack live outside the sandbox and are not accessible from within (e.g. tricks like return-oriented programming are not possible in WASM.
Instead of popping up an alert, you could have requested the deletion of all files in the cloud storage.
I also wonder why stack canaries wouldn't work on WASM, since the compiler creates stack frames on the data-only stack just the same (but maybe Clang's `-fstack-protector` doesn't work for some reason in WASM, I'll actually need to check that).