You didn't explicitly say this, but for anyone who might misinterpret your comment to imply that any memory-unsafe should be specifically targeted at certain small domains:
A vast swath of the programming world doesn't need the level of memory safety that Rust has: apps and webapps are generally sandboxed and only talk to a trusted first-party domain, and games don't need memory safety if they're single player, or even multiplayer co-op against AI. There are a lot of aspects of the industry like this.
We do need memory safety in any case that receives untrusted input (for security reasons), cases that handle multiple users' data (for privacy reasons), and safety critical software. There are plenty more cases like these too. Languages like Rust (or even more memory-safe languages) are a stellar choice for this side of the programming world, but not necessarily the other side.
Creating simple languages to serve the purposes best served by simple languages is a good thing, and I celebrate and applaud Odin and Zig for that. It's up to the individual developer to make a responsible choice based on their situation, and any developer that uses the wrong language for the wrong situation is indeed guilty of lowering the bar.
Yeah, to be clear, some domains are different. Gaming is one example of a domain where "best effort" memory safety is perfectly acceptable. Would I prefer full memory safety? Sure, but we don't see games as an attack vector in the wild very often and there are good reasons for that.
If someone wants to build a game in a language that's best-effort memory safety go for it. Similarly, CLI applications are often never called from an untrusted context and often provide semantic power that is equivalent to code execution anyways, so again I'd love to see memory safety, but I'm not going to care that much.
But these are exceptions - you'd still want to way whatever you're getting from memory-unsafe-language-X against just using a memory safe language. The default should be memory safety. Given that we have Go, Rust, Java, and more, there are few situations where memory safety isn't an easy option. Not zero, just few.
Even without it being an attack vector, memory unsafety in games can suck as a user. I play a game that’s high stakes, when you die you lose your gear. I’ve lost two full sets of endgame gear recently because of a crash due to an EXCEPTION_ACESS_VIOLATION. I found it kinda funny in a dark way. Anyway, cheats can also happen due to these sorts of issues. And let’s not even start about anticheat; if Battleye or god forbid Vanguard has a memory unsafety issue that’s exploitable, a lot of people are going to be in a very bad place.
Single player games maybe but they can still cause problems the end user sees.
EXCEPTION_ACCESS_VIOLATION is well-defined & memory safe. That's just a crash, same thing that happens when Helix crashes because it called .unwrap() on an error. It's correctness that affects the user experience, not memory safety.
From a cheating perspective, memory safety is entirely irrelevant when the game code is running on the users' computers, where they have full control over the machine code of the client, their own RAM, and the bytes being sent to the network.
There are plenty of important use cases to care about memory safety, but video games executing on players' computers ain't it.
> where they have full control over the machine code of the client,
Part of the state of modern anti-cheat is developers taking extreme measures to fight exactly this. Developers don’t just throw their hands up in the air and say it’s unfixable. The softwares I mention run as kernel modules, hook into all sorts of parts of your system, and sometimes even stream new mitigations to be executed as the game is running. That’s why an RCE in this software would be extremely bad.
EXCEPTION_ACCESS_VIOLATION itself is well-defined and memory safe, but the program constructs that cause it are generally not. A use-after-free or null pointer dereference may cause an access violation in one run but corrupt memory and keep going in another. This is a very typical approach to building an exploit- find something like this and then tweak the input to turn it into something worse.
This also plays into undefined behavior- unless the source language itself guarantees that a particular program will generate an access violation, chances are the access violation only happens by luck. For example, null pointer dereference is typically UB rather than specified as a crash, because while accessing the actual address 0 will reliably cause an access violation (assuming you are in such an environment), field projection and array indexing can move that address up out of the 0 page and lead to arbitrary memory access.
> EXCEPTION_ACCESS_VIOLATION is well-defined & memory safe. That's just a crash, same thing that happens when Helix crashes because it called .unwrap() on an error.
Just because both of those things cause a crash doesn't mean they are the same.
Crashing due to an incorrect .unwrap() is a bug in the business logic of the application, the developer made a wrong assumption.
EXCEPTION_ACCESS_VIOLATION is a crash due to a memory issue that a memory safe language would have prevented.
> It's correctness that affects the user experience, not memory safety.
Memory safety is part of correctness, your program can't be correct if it crashes with EXCEPTION_ACCESS_VIOLATION.
Sure, I think all developers, virtually regardless of domain, should strive for higher quality software. The bar is really low. But the fight I choose is memory safety in cases where end user security will be harmed without it - to me, that's such a pathetically low bar already, surely people can't argue against it (they can and they do lol I hate this industry tbh).
I'm not sure I'd characterize Rust as an easy enough option for most people/cases, or that there's just a "few" situations, but apart from that I like your perspective, well said.
> games don't need memory safety if they're single player, or even multiplayer co-op against AI.
I've seen a bug in handle convert function* in Warcraft 3 that resulted in bunch of maps, some singleplayer, some coop, some MP that lead to crashes (E can't find much material about it).
So no, memory security matters even in SP games with user made content and bug. Attacker can spoof or take a user mod and exploit it for their own gains
* Warcraft 3 had a really rudimentary language called JASS, however due to a way some handle convert function could leak address of objects, an entire new language stack (vJASS) was formed around it. Many maps embraced vJass. And several years later it turned out that function could be exploited.
> I've seen a bug in handle convert function* in Warcraft 3 that resulted in bunch of maps, some singleplayer, some coop, some MP that lead to crashes (E can't find much material about it).
Crashes that didn't cause a lot of damage. Using a language like Rust could add way more overhead than it's worth. The GP's point was that some applications just don't require complete safety, a crash or two won't kill anyone (which could happen literally in a hospital computer for example).
> Bug Fix: Fixed an __exploit that allowed users to execute arbitrary code__ in Warcraft 3 Funmaps.
> Bug Fix: Fixed several World Editor crashes.
> New JASS has table functions have been added to the Warcraft 3 World Editor, to fix unsafe type casting.(Save Item Handle, Unit Handle, Load Item Handle, Load Unit Handle, Get Handle ID).
EDIT: I was right originally, game error in modded games can lead to horrible exploits.
A vast swath of the programming world doesn't need the level of memory safety that Rust has: apps and webapps are generally sandboxed and only talk to a trusted first-party domain, and games don't need memory safety if they're single player, or even multiplayer co-op against AI. There are a lot of aspects of the industry like this.
We do need memory safety in any case that receives untrusted input (for security reasons), cases that handle multiple users' data (for privacy reasons), and safety critical software. There are plenty more cases like these too. Languages like Rust (or even more memory-safe languages) are a stellar choice for this side of the programming world, but not necessarily the other side.
Creating simple languages to serve the purposes best served by simple languages is a good thing, and I celebrate and applaud Odin and Zig for that. It's up to the individual developer to make a responsible choice based on their situation, and any developer that uses the wrong language for the wrong situation is indeed guilty of lowering the bar.