4 ms·

Interesting comment. I'm not sure Rust's safety guarantees are what many would consider merely an "implementation detail". Aren't the merits and caveats in any

by ovao 10y ago

Interesting comment. I'm not sure Rust's safety guarantees are what many would consider merely an "implementation detail". Aren't the merits and caveats in any programming language (not with regard to its overall ecosystem), just implementation details? Or is my line of thinking not correct about that? I'd agree with you on this point if a language really marketed its relatively simple safety facilities — like, say, C++11's std::shared_ptr — but relatively high-level (or perhaps "mid-level") guarantees provided by the standard or by the implementation strike me as features of real substance. Something substantial enough that I would take it into account in choosing a language, among many other things, and I think Rust's are relevant to a large number of systems. From what I can tell Rust is being marketed well enough to create a lot of enthusiasm. I don't know if that's necessarily an indication that it's being marketed properly (by whatever definition of "properly" makes sense).

jolux 10y ago
The safety features of Rust are core to the design of the language, that's what makes it so effective. It essentially takes part of what makes the design of pure functional programming so safe and makes it highly performant and pragmatic for a systems programming context. An implementation detail would be like the intricacies of better code generation, which is not at all key to Rust. Granted, it's "C fast," but the whole point of the safety features is that they are intrinsic and pervasive to how the language functions so that the programmer is not allowed to make certain kinds of mistakes that C and C++ are totally fine with and will generate crashing code for. It's not just about making unsafe programming practices safe through better compiler practices, it's about stopping the unsafe programs before they reach the compilation step.
- akiselev 10y ago
  > It's not just about making unsafe programming practices safe through better compiler practices, it's about stopping the unsafe programs before they reach the compilation step. I would like to add to the end of that: "...unless you explicitly tell the compiler to do it." I can't think of anything that you can do in C that you can't do in Rust unsafe blocks, you just have to tell the compiler explicitly.
  - jolux 10y ago
    Yes, the unsafe parts are always explicit so you never forget about the gravity of working with unsafe code.
buzzybee 10y ago
Safety is definitely part of implementations at least as much as it is a property of languages. The baseline measure of that is with compiler error messages. Classically bad(as in, this is what you'd get in many environments circa 1980) error messages just terminate and say "error code 100", and then you'd go look in your reference manual to figure out what error code 100 meant, because the system was too crude to have actual error printouts. Maybe you'd use a machine code monitor, or roll your own trace logs. So you'd be mostly in the dark as to what is wrong and how to fix it, and debugging was default-hard rather than default-trivial, shaping the entire nature of the programs you wrote towards easy wins that would not break catastrophically. Rust, on the other hand, has invested so much into its error technology. It tells you what the offending lines are, the type of error, and gives a best-effort to point out the underlying issue causing the error. It guides you towards a code style that best exploits the nature of the errors, allowing you to take "risky" moves that only the compiler can successfully guarantee, and in-the-large, to an architecture that follows the grain of the compiler instead of fighting with it.

by ovao 10y ago

jolux 10y ago

The safety features of Rust are core to the design of the language, that's what makes it so effective. It essentially takes part of what makes the design of pure functional programming so safe and makes it highly performant and pragmatic for a systems programming context. An implementation detail would be like the intricacies of better code generation, which is not at all key to Rust. Granted, it's "C fast," but the whole point of the safety features is that they are intrinsic and pervasive to how the language functions so that the programmer is not allowed to make certain kinds of mistakes that C and C++ are totally fine with and will generate crashing code for. It's not just about making unsafe programming practices safe through better compiler practices, it's about stopping the unsafe programs before they reach the compilation step.

akiselev 10y ago
> It's not just about making unsafe programming practices safe through better compiler practices, it's about stopping the unsafe programs before they reach the compilation step. I would like to add to the end of that: "...unless you explicitly tell the compiler to do it." I can't think of anything that you can do in C that you can't do in Rust unsafe blocks, you just have to tell the compiler explicitly.
- jolux 10y ago
  Yes, the unsafe parts are always explicit so you never forget about the gravity of working with unsafe code.

buzzybee 10y ago

Safety is definitely part of implementations at least as much as it is a property of languages. The baseline measure of that is with compiler error messages. Classically bad(as in, this is what you'd get in many environments circa 1980) error messages just terminate and say "error code 100", and then you'd go look in your reference manual to figure out what error code 100 meant, because the system was too crude to have actual error printouts. Maybe you'd use a machine code monitor, or roll your own trace logs. So you'd be mostly in the dark as to what is wrong and how to fix it, and debugging was default-hard rather than default-trivial, shaping the entire nature of the programs you wrote towards easy wins that would not break catastrophically. Rust, on the other hand, has invested so much into its error technology. It tells you what the offending lines are, the type of error, and gives a best-effort to point out the underlying issue causing the error. It guides you towards a code style that best exploits the nature of the errors, allowing you to take "risky" moves that only the compiler can successfully guarantee, and in-the-large, to an architecture that follows the grain of the compiler instead of fighting with it.