> PDF and spreadsheet vulnerabilities are very common.
True. The issue is that they operate on complex input that can arrive from anywhere. So if you download a malicious PDF file it can exploit you.
But GP's other example is valid: A singleplayer game running locally will only run the game assets from the developer. The user input (in almost all games) is very limited. Exploits are not a major issue in such a program.
There is room for languages like Zig. There is also the potential for it to be used in improper places, but so far the majority of applications I've heard of seem reasonable to me.
> Then there’s the productivity gain you get by not having to spend hours debugging obscure memory and threading bugs.
Also true. But there are the other usual tradeoffs, such as that a language focused on simplicity and correctness, like Zig, might reduce other sources of bugs.
Some developers might be more productive with Rust, others with Go, others with Zig. I don't think there's a single answer here. As an example of another related tradeoff, fast compile times often help debugging, which is an advantage of Go and Zig.
> A singleplayer game running locally will only run the game assets from the developer. The user input (in almost all games) is very limited. Exploits are not a major issue in such a program.
Nothing is that isolated anymore. Can you find a modern single-player game on Steam that doesn't talk to the network for analytics or DLC or sending crash reports to the developer? I'm sure they exist, but they're likely exceptionally rare.
For Zig to be helpful in the modern world, it will need memory safety guarantees and it will need them on by default. It's totally OK if those are easier to switch off than in Rust so that you can do the low-level things performantly and easily. But you have to start from a default position of safety.
Even if a game sends crash reports etc., it could be safe enough. Making a secure connection to a known remote server isn't a major source of exploits. (Look for example at the list of exploits against Firefox and Chrome - stuff like that isn't even noticeable.)
I disagree every language needs to start with the same defaults as Rust. Rust proved its approach is a useful one, and Rust is a huge asset to our industry, but we also benefit from exploring other approaches.
True. The issue is that they operate on complex input that can arrive from anywhere. So if you download a malicious PDF file it can exploit you.
But GP's other example is valid: A singleplayer game running locally will only run the game assets from the developer. The user input (in almost all games) is very limited. Exploits are not a major issue in such a program.
There is room for languages like Zig. There is also the potential for it to be used in improper places, but so far the majority of applications I've heard of seem reasonable to me.
> Then there’s the productivity gain you get by not having to spend hours debugging obscure memory and threading bugs.
Also true. But there are the other usual tradeoffs, such as that a language focused on simplicity and correctness, like Zig, might reduce other sources of bugs.
Some developers might be more productive with Rust, others with Go, others with Zig. I don't think there's a single answer here. As an example of another related tradeoff, fast compile times often help debugging, which is an advantage of Go and Zig.