3 ms·
I don't have a strong stance on the overall issue of whether it made sense for them to port like this, but I feel like this misunderstands the value proposition
by saghm 4mo ago
I don't have a strong stance on the overall issue of whether it made sense for them to port like this, but I feel like this misunderstands the value proposition of Rust. The point of Rust is not and has never been "make literally everything safe", it's "push the unsafe boundary as low as possible and keep as much as possible above it so that you can reduce the surface area for unsafety and more easily find bugs in the unsafe code". For some things, that means you can rely only on unsafe code that's in the standard library implementation, which is awesome. For others, you might need to rely on FFI to interface with external libraries, and that's obviously less ideal but still provides tangible value. In the worst case, you might need to write unsafe Rust code yourself, but you can at least take efforts to minimize the surface area of it by wrapping it in safe abstractions that enforce the invariants you need to uphold safety.
The idea that "anything other then pure safe Rust is useless" is common (even among some Rust proponents, but generally not the most experienced ones), but it's a pretty fundamental misconception of what Rust actually offers. Safety is a spectrum, not a binary, and while the extreme end of "everything is guaranteed to be safe no matter what" is nice when you can get it, Rust is literally designed to solve the problem of giving you the ability to slide along the spectrum to calibrate to the most amount of safety you an achieve rather than being all-or-nothing.
If you still think there's no value in enforcing safety outside of the lowest level stuff like JIT, I'd suggest being more explicit about why you're confident that memory safety bugs wouldn't be a concern outside of those contexts. I've yet to hear an argument for why I shouldn't be concerned about memory unsafety in even relatively mundane code in memory unsafe languages that doesn't basically boil down to "just be really really careful", which I'd argue has been empircally shown to not work even a little bit no matter how skilled the programmers writing the code are.
- the__alchemist 4mo ago> Rust is not and has never been "make literally everything safe", it's "push the unsafe boundary as low as possible and keep as much as possible above it so that you can reduce the surface area for unsafety and more easily find bugs in the unsafe code". Another definition: Rust is a lang to "Run fast and low-level software/firmware, with nicer tools, features, and syntax than the other langs which can do this"! Obviously, the value proposition you find in this case depends on the subjective nature of that regarding rust vs zig!
- saghm 4mo agoI don't think I agree with this framing because "definition" implies comprehensiveness in a way that "here are some properties which may not cover everything that's relevant" does not. Your "definition" implicitly ignores the safety mechanism that Rust has and Zig lacks, which does a lot of rhetorical work into making it seem like the only difference is in "flavor" rather than "substance". My argument that there is a meaningful difference in substance, just not the one that the parent comment (and plenty of others) expected.
- the__alchemist 4mo agoSemantics on "definition". "safety" is not why I use and love it. I brought this up because someone who hasn't used Rust, but reads about it may assume it's a "safe" language; I would describe it instead as a nice all-around language.
- saghm 4mo agoI don't know if I totally agree with your characterization here either. I'd argue that if you're not actively writing unsafe code, then you are using it as a safe language, in the same way that Python and Java are also safe languages. Yes, I also think it's a quite nice language, but safety is important enough that any time you're comparing a language that can be used safely to one that fundamentally can't enforce safety, framing the choice as purely ergonomic (even implicitly) is misleading.