btw note that you're arguing this point in a the thread of a blog post about a feature that is all about maintaining safety while not paying for it at runtime. There's an entire section dedicated to explaining this point.
If it's a program you wrote to run on your on hardware, feel free. But in reality most programmers write programs for other people's computers, or just write programs because it's fun or pays well, and then their work gets integrated into a larger whole at a much later date, and then it's run in contexts the original author never imagined, long after they move on. Safety checks catch the base-level logic bugs that would otherwise cause programs to go silently wrong and misbehave in complex and inscrutable ways. Disabling them is not just living dangerously, it's a moral hazard; the programmer doesn't suffer the consequences, users do. It's not your program or computer at risk, but someone else's. I don't know how as a profession we're so cavalier with shipping exposed whirling knives, but we are.
> the programmer doesn't suffer the consequences, users do.
The same is true of poorly performing programs. My computer's resources are not the programmers' to waste, yet they routinely do waste it to save themselves time[0].
> I don't know how as a profession we're so cavalier with shipping exposed whirling knives, but we are.
That's a separate problem than not handcuffing programmers and forcing them into safety checks. Why should Zig force this?
Like, I just don't even get what you're complaining about here. The default build mode and the recommended release one insert the check. Checks can additionally be enabled and disabled on a scope-by-scope basis. What exactly do you want? Just eliminate ReleaseFast as an option and give people more reasons to go back to footgun-laden C because it'll be the only way to eliminate a bounds check in a tight loop hot spot?
[0] Yes, I know this isn't due to safety checks in the vast majority of circumstances, that's not the point. I have nothing against safety checks, my problem is with the mentality that it should not be possible to disable them. Even Rust has `unsafe`.
the mere naming of the keyword `unsafe` has been a wholly unintentional disaster for programming in general as more and more people use Rust, because "safe"/"safety"/"unsafe" are sort of emotionally-loaded words in English, and it's led to people to build mental heuristics about the pros and cons of "safe" and "unsafe" code which may be subtly incorrect. the language feature itself is completely reasonable of course, given the design decisions of the language, but as Andy said elsewhere in this comments thread:
> Rust evangelists need to be careful because in their zeal they have started to cause subtle errors in the general knowledge of how computers work in young people's minds. Ironically it's a form of memory corruption.
I'm not even a zig user or fan or anything and I don't have any real opinion about Rust, either, except for completely agreeing with this analysis based on how I've seen Rust evangelists talk online. I'm not sure what the solution to this is, but it seems like it's just going to get worse over time as Rust becomes more popular and gains market share.
The term "memory safety" is much older than Rust and very common, the "unsafe" keyword is based on that existing concept and I think that consistency is the right choice here. I also don't have the impression that this is communicated in a way that leads to confusion with "correctness".
What alternative name would you prefer to express the collection of memory safety features in programming languages?
If we go so far as to say that using anything unsafe is dangerous and a "moral hazard" then we would also have to disqualify Rust, C#, and any other language that allows unsafe escape hatches (especially in dependencies).
So isn't it on the programmer to ensure the safety checks are enabled if appropriate? I agree with the gist of your statement, I'm just not sure how this is the responsibility of the language itself. It ships with the option to build via a safe mode. I don't think it's a moral imperative of the language designer to ship without an unsafe mode. Even rust has unsafe blocks.
In most engineering professions, it's the engineer's responsibility to ensure appropriate levels of safety, not the CAD software used to build the blueprints. But every situation doesn't have the same level of safety required; backyard sheds don't have the same needs as skyscrapers.
Most engineering disciplines are considerably more regulated than software development, and for good reason; bridges and skyscrapers falling down can kill people. Even electrical engineering and device manufacturing have to fit in with standards that address shock hazard and EMF interference.
I actually do think it is the responsibility of the language and runtime system to ensure some base-level safety of programs. The one constant over the years is that programmers keep making mistakes. No matter how much they keep yelling "trust us", they (we) just keep screwing up. That's not to pillory us programmers. It's just the facts that everyone screws up. In some sense, engineering is putting processes and procedures and checks in place that move human fallibility out of the critical load-bearing situations so that a simple whoops or memory slip doesn't kill people or ruin things.
I am not claiming all of these would've been prevented by bounds checking arrays, or even memory safety in general. The point is that security is not optional just because it's a game.
Now suppose your game runs in a WASM sandbox and re-run those scenarios. What do you gain from bounds checks?
I'm not suggesting that shipping without bounds checks is wise or leads to a
better product. However I do think with /some games/ security is basically not a concern.
Heartbleed still happens inside a sandbox, because it's the sandboxed memory that leaks. For multiplayer games specifically, that can be a client auth key that can be used to impersonate you.
I think it's more like (assuming it does actually go out of bounds at some point):
30% chance of core dump right away
20% chance of core dump at some point after errant write
40% chance it never crashes in testing
5% chance it doesn't crash the first year after shipping
5% chance it never crashes
With an explicit bounds check, all of these scenarios result in a crash at the exact location where the program first violated safety[1]. The developer gets a source-level crash and doesn't spend the first 20 minutes just trying to figure out what the crash dump even means.
[1] Hopefully with a complete stacktrace, maybe even the index and length values!
It's time we recognized that all our tooling should be designed to help us programmers who do have bugs in our program. Like, this crashing part is the normal part that all the tools should help deal with.
The meaningless error message can be entered into Google and the user can find a thread about how to fix their specific problem instead of wading through endless threads of similar-but-unrelated problems.
Sure, but I don't agree that disabling safety checks is an "optimization". It is a regression in functionality that is betting on nothing going wrong.
Bounds checks do not cost much[1]. Maybe if a bounds check disables vectorization[2].
[1] https://blog.readyset.io/bounds-checks/
[2] https://github.com/matklad/bounds-check-cost
There are a lot of techniques to remove bounds checks, e.g. in counted loops [3][4].
[3] https://ieeexplore.ieee.org/document/5381765
[4] https://en.wikipedia.org/wiki/Bounds-checking_elimination