Our great sponsors
-
zig
General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
I am only moderately surprised by this, because I have seen some less egrigious intermittent miscompilations in stage1 such as this one: https://github.com/ziglang/zig/issues/11786
I cannot provide the full program in which it fails, and the small programs I tried did not cause it to fail.
I sort of expect these things to be fixed though. Like, eventually both Zig and unsafe Rust will actually have defined semantics, and eventually expressions containing `if (false) { X(); }` will not call X, and so on.
I do agree that the term "safe" shouldn't be used as a shorthand for "memory-safe". Memory safety is only a subset of correctness, and "safe" in my ears sounds misleadingly like a stronger promise. (And the "unsafe" keyword does not necessarily mean memory-unsafe, but simply unchecked.) There's no real harm in this, but I'm a fairly sensitive person and can't help but feel shamed even when I have a case that legitimately requires the use of unsafe Rust, which can be mildly frustrating. That's something that I need to get over, though; I don't think Rust should change.
To be clear, I really like Rust (oh, that I could never write C++ again). There are some astonishingly underdeveloped parts here and there [1], and I've a few pet peeves, but it's fun to use and I think it's a great step in the right direction. I'm really grateful to all the people who work on it.
[1] I just ran into https://github.com/rust-lang/rust/issues/55795, for example.