5 ms·

Agree with this take. I think about Rust's memory safety about as much as I think about other language's garbage collectors. Which is to say occasionally, but c

Agree with this take. I think about Rust's memory safety about as much as I think about other language's garbage collectors. Which is to say occasionally, but certainly not every day. It's the underlying design that makes the language ergonomic, but not a daily consideration for average users. What I appreciate day-to-day about Rust is that it encourages (coerces you at compile time) to get things right. If you did not consider all possible code paths, you will hear about it immediately - not in a bug report 6 months from now. Where things are not right, they're obviously not so (ie unwrap). This gives me confidence that the rust code I ship will run in prod without failing due to some unforeseen error. Every error condition, aside from catastrophic hardware failure, has been accounted for in the AST of the program. That's not "proven correct" but it's close enough for production work.

fargle 2y ago
i don't disagree, but will register a bit of counter argument. i think it's great that the software engineering discipline is maturing. i think it's great that we study formal semantics and work towards making it easier to create correct programs and harder to create incorrect ones. new-thing-better, gotcha. but old-thing-bad-shouldn't-they-have-ism i do not like at all. i think it is a misrepresentation of what "C" was, and is, to falsely compare it with a modern "safe" language (we saw this before with java. oops i mean pascal. oops i mean ada, oops lisp, etc.). it was never meant to be a "safe" language. it was, and is, basically a portable high-level assembler. it allows, but does not enforce, "structured programming" and user defined types, and was portable. that was at the absolute forefront in the 1970s and 1980s. and the productivity was "off-the-chart". sure, your UNIX might crash now and then, but you "just yell down the hall and reboot it" instead of waiting on a multi-decade project to "do it right" to materialize. so what now? 50 years hence? is it an appropriate language for string parsing in a security sensitive application? probably not. is it a "bad" language, or inappropriate for some other task? and why aren't we wailing and screeching about the lack of memory safety in assembler, for example? the problem to me is not the language, but the application of it. say you have an application A where language X is a better fit than language Y, but they used X. you don't call out the designers of language X for not anticipating A, you should instead build A' using language Y and let it prove itself.
- thecodedmessage 2y ago
  This is a fair defense of C, but C++ is what deserves the heat. C is portable assembly, C++ isn’t.
belter 2y ago
> Every error condition, aside from catastrophic hardware failure, has been accounted for in the AST of the program. That's not "proven correct" but it's close enough for production work. But not all possible program inputs...Different space size, but still relevant for some production scenarios.
- perrygeo 2y ago
  Yes, but I can be assured that any input will follow one of the code paths that I explicitly wrote. There's no hidden runtime path that will bite me later, meaning that I had to at least reason about every non-happy path at some point in the dev process. It doesn't make the output "correct" but it's more likely to be correct than programming with happy-path-only optimism.

fargle 2y ago

i don't disagree, but will register a bit of counter argument. i think it's great that the software engineering discipline is maturing. i think it's great that we study formal semantics and work towards making it easier to create correct programs and harder to create incorrect ones. new-thing-better, gotcha. but old-thing-bad-shouldn't-they-have-ism i do not like at all. i think it is a misrepresentation of what "C" was, and is, to falsely compare it with a modern "safe" language (we saw this before with java. oops i mean pascal. oops i mean ada, oops lisp, etc.). it was never meant to be a "safe" language. it was, and is, basically a portable high-level assembler. it allows, but does not enforce, "structured programming" and user defined types, and was portable. that was at the absolute forefront in the 1970s and 1980s. and the productivity was "off-the-chart". sure, your UNIX might crash now and then, but you "just yell down the hall and reboot it" instead of waiting on a multi-decade project to "do it right" to materialize. so what now? 50 years hence? is it an appropriate language for string parsing in a security sensitive application? probably not. is it a "bad" language, or inappropriate for some other task? and why aren't we wailing and screeching about the lack of memory safety in assembler, for example? the problem to me is not the language, but the application of it. say you have an application A where language X is a better fit than language Y, but they used X. you don't call out the designers of language X for not anticipating A, you should instead build A' using language Y and let it prove itself.

thecodedmessage 2y ago
This is a fair defense of C, but C++ is what deserves the heat. C is portable assembly, C++ isn’t.

belter 2y ago

> Every error condition, aside from catastrophic hardware failure, has been accounted for in the AST of the program. That's not "proven correct" but it's close enough for production work. But not all possible program inputs...Different space size, but still relevant for some production scenarios.

perrygeo 2y ago
Yes, but I can be assured that any input will follow one of the code paths that I explicitly wrote. There's no hidden runtime path that will bite me later, meaning that I had to at least reason about every non-happy path at some point in the dev process. It doesn't make the output "correct" but it's more likely to be correct than programming with happy-path-only optimism.