> 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?
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`.