4 ms·
It's not clear if you are continuing to refer to Rust as your parent post did, but if so, note that this is not the standard Rust meaning for "unsafe". Using it
by shepmaster 7y ago
It's not clear if you are continuing to refer to Rust as your parent post did, but if so, note that this is not the standard Rust meaning for "unsafe". Using it in such a way makes it more complicated to discuss and explain the Rust-specific meaning.
- shadowgovt 7y agoThank you for the clarification; I was using 'unsafe' colloquially and not in the Rust sense.
- ferzul 7y agoIf Rust devs took an everyday English word and gave it a different meaning, isn't it their fault when they have to train everyone into discarding their intuitions? It sounds like it means “code that is unsafe for a particular reason”; name the reason and leave developers capable of criticising code that is unsafe for other reasons, too. Unchecked Exception throwing code and stringly typed code are both unsafe. The world is better if we can call spades spades, instead of pitchfork style digging implements, because you want to protect playing card manufacturers.
- shepmaster 7y ago> If Rust devs took an everyday English word and gave it a different meaning Perhaps, but if we had come up with a new word, you or someone else would complain that we had done that instead of using a word that people already "understood". :-) English is a language full of elision, and there's nothing inherently wrong with using one word for closely related meanings. When being precise, Rust uses the term "memory unsafety", but we humans usually shorten that to just "unsafety" because we are lazy. My point was merely to state that a function throwing an exception [1] doesn't introduce memory unsafety. --- [1] Notably, we call this "panicking" in Rust-speak; does the fact that we call it something different from "exceptions" confuse people? Probably at least one.
- wizzwizz4 7y agoWe call it panicking because there's no assumption that you're always able to catch panics. Panicking is an AAAH EVERYTHING WENT WRONG kind of thing, which might trigger an immediate abort if the program is compiled in super-ultra-speedy-make-debugging-really-hard mode; if your code panics, it's always the programmer's fault. The language provides a way of kinda-sorta recovering from an everything-goes-wrong situation only to be nice to you, and not because that's a thing that's generally possible. You can't always recover from a segfault, or a buffer overrun, or the rest of the kind of things that cause panicking, even if you know that they're theoretically possible in advance, because if you could you would've fixed them already. The best you can do is make your web server return a 500, send logs, ditch its cache, restart in a sane state and hope for the best. You're not recovering that half-finished task, because the programmer can't reason about the program state in a situation where their code has been shown to be wrong. Panics are only for exceptional failure cases. If this confuses people, it's (probably) because they only thought they understood; they needed confusing.
- shadowgovt 7y agoAll of that having been said... If you're talking about Rust, I can't comment directly because I haven't used Rust, but I've totally used Go's panic / recover to implement "return" and "break loop" in a language interpreter. I should really rewrite that thing to do something more sane like bundle up a continuation state to return to, but I was feeling lazy. ;)