4 ms·

> It's like buying a Toyota, you know from the brand alone that you're getting a certain baseline level of reliability, maintainability, durability, and longevi

> It's like buying a Toyota, you know from the brand alone that you're getting a certain baseline level of reliability, maintainability, durability, and longevity. Rust is like the Toyota of programming languages - it can produce many different types of cars/programs, but they're all guaranteed to come with a baseline level of assurance, and to eliminate common classes of problems that degrade the end-user experience. It's possible to make buggy, slow, crappy software in any language. Rust is no exception. Nobody should derive any confidence from the language a product is written in.

uoaei 5y ago
This is true and also mostly unhelpful. It's possible to build a car without a muffler. Does that mean it happens often enough that we need to dedicate a whole pooh-pooh session to the possibility? Is a manufacturing process not more likely to be useful if it prevents this error from ever occurring?
jolux 5y ago
> It's possible to make buggy, slow, crappy software in any language. True. > Rust is no exception. Also true. > Nobody should derive any confidence from the language a product is written in. This, on the other hand, is a non-sequitur, or at least it's too strong, because Rust can do things that C can't do: safe deterministic memory management and safe concurrency without data races. These things are not just available, they are the defaults in Rust. You have to go out of your way to get these things wrong. So, I wouldn't derive absolute confidence from an application being written in Rust. But I'd be willing to bet a whole lot that it has fewer memory bugs than an equivalent application written in C.
- SkyMarshal 5y ago
  > they are the defaults in Rust. Exactly, this is what I should have explicitly said. Language defaults have a powerful effect on a project's norms and culture. > You have to go out of your way to get these things wrong. Yes, you actually have to try to write shitty Rust code, at least where there are defaults that prevent it. Thus the average Rust program will have that baseline level of quality. Like TQM/TPM/Six-Sigma for manufacturing software.
  - pjmlp 5y ago
    Like ActixWeb?
    - jolux 5y ago
      Do you think Actix Web would be safer if it were written in C++?
      - pjmlp 5y ago
        Probably not, the point was that being in Rust wasn't either.
        mmstick76 5y ago
        But the point is the exact opposite because any use of unsafe is clearly marked as such, and therefore a code audit will instantly find its use and question it. Hence the fallout surrounding it.
        pjmlp 5y ago
        How do you find unsafe on a binary library? Also that is besides the point, unsafe only deals with a very specific cause of errors that plague C code bases (and those of languages copy-paste compatible with it). Rust's unsafe wouldn't have done anything to protect against an hypotetical log4r.
        jolux 5y ago
        My point is that Actix Web was still safer than it would have been if it were written in C++ (which is Rust’s whole goal as far as safety), and moreover the norms of the Rust community are so strong that most of the unsafe usage has since been removed, since it was unnecessary. Unsafe deals with memory errors, which are consistently the largest class of security vulnerabilities in native codebases. This is uncontroversial at this point. Rust won’t protect you from log4j, but it never claimed to. Java still protects you from mishandling memory, despite all the stupid automatic classloading features we keep discovering in it.
- LoveMortuus 5y ago
  Non-sequitur definition: noun a conclusion or statement that does not logically follow from the previous argument or statement. "his weird mixed metaphors and non sequiturs"
posnet 5y ago
There has to be a middle ground between "Nobody should derive any confidence from the language a product is written in" and "I only use products written in language X". You shouldn't dervive all confidence in a product from it's implementation language, but when you are looking at all available products and need to filter down to ones you might be interested in. Implementation language can be a useful litmus test for understanding how it might behave without doing a complete in depth evaluation. For example if I learn that a desktop application is written in javascript, it is likely to be using electron or an OS webview. Or if an application is written in C++ it is unlikely to have GC pauses cause stuttery UI. Both of those assumptions may not be true (Sciter for JS and Boehm GC for C++ respectively). However those assumptions are a useful starting point unless proven otherwise.
SkyMarshal 5y ago
> It's possible to make buggy, slow, crappy software in any language. Technically it's possible, but you have to try a lot harder to do it in Rust than most other systems languages.

uoaei 5y ago

This is true and also mostly unhelpful. It's possible to build a car without a muffler. Does that mean it happens often enough that we need to dedicate a whole pooh-pooh session to the possibility? Is a manufacturing process not more likely to be useful if it prevents this error from ever occurring?

jolux 5y ago

> It's possible to make buggy, slow, crappy software in any language. True. > Rust is no exception. Also true. > Nobody should derive any confidence from the language a product is written in. This, on the other hand, is a non-sequitur, or at least it's too strong, because Rust can do things that C can't do: safe deterministic memory management and safe concurrency without data races. These things are not just available, they are the defaults in Rust. You have to go out of your way to get these things wrong. So, I wouldn't derive absolute confidence from an application being written in Rust. But I'd be willing to bet a whole lot that it has fewer memory bugs than an equivalent application written in C.

SkyMarshal 5y ago
> they are the defaults in Rust. Exactly, this is what I should have explicitly said. Language defaults have a powerful effect on a project's norms and culture. > You have to go out of your way to get these things wrong. Yes, you actually have to try to write shitty Rust code, at least where there are defaults that prevent it. Thus the average Rust program will have that baseline level of quality. Like TQM/TPM/Six-Sigma for manufacturing software.
- pjmlp 5y ago
  Like ActixWeb?
  - jolux 5y ago
    Do you think Actix Web would be safer if it were written in C++?
    - pjmlp 5y ago
      Probably not, the point was that being in Rust wasn't either.
      - mmstick76 5y ago
        But the point is the exact opposite because any use of unsafe is clearly marked as such, and therefore a code audit will instantly find its use and question it. Hence the fallout surrounding it.
        pjmlp 5y ago
        How do you find unsafe on a binary library? Also that is besides the point, unsafe only deals with a very specific cause of errors that plague C code bases (and those of languages copy-paste compatible with it). Rust's unsafe wouldn't have done anything to protect against an hypotetical log4r.
        jolux 5y ago
        My point is that Actix Web was still safer than it would have been if it were written in C++ (which is Rust’s whole goal as far as safety), and moreover the norms of the Rust community are so strong that most of the unsafe usage has since been removed, since it was unnecessary. Unsafe deals with memory errors, which are consistently the largest class of security vulnerabilities in native codebases. This is uncontroversial at this point. Rust won’t protect you from log4j, but it never claimed to. Java still protects you from mishandling memory, despite all the stupid automatic classloading features we keep discovering in it.
LoveMortuus 5y ago
Non-sequitur definition: noun a conclusion or statement that does not logically follow from the previous argument or statement. "his weird mixed metaphors and non sequiturs"

posnet 5y ago

There has to be a middle ground between "Nobody should derive any confidence from the language a product is written in" and "I only use products written in language X". You shouldn't dervive all confidence in a product from it's implementation language, but when you are looking at all available products and need to filter down to ones you might be interested in. Implementation language can be a useful litmus test for understanding how it might behave without doing a complete in depth evaluation. For example if I learn that a desktop application is written in javascript, it is likely to be using electron or an OS webview. Or if an application is written in C++ it is unlikely to have GC pauses cause stuttery UI. Both of those assumptions may not be true (Sciter for JS and Boehm GC for C++ respectively). However those assumptions are a useful starting point unless proven otherwise.

SkyMarshal 5y ago

> It's possible to make buggy, slow, crappy software in any language. Technically it's possible, but you have to try a lot harder to do it in Rust than most other systems languages.