8 ms·

Why shouldn't the unexperienced systems programmers go "all in" by using Rust, then? The first priority for them should be memory safety. Not to mention that Ru

Why shouldn't the unexperienced systems programmers go "all in" by using Rust, then? The first priority for them should be memory safety. Not to mention that Rust has more ergonomic features and stronger ecosystems.

throwawaymaths 3y ago
Why should the first priority be memory safety? If the first priority is always memory safety, then rust should not have `unsafe` keyword. Existence of `unsafe` implies that, even rust, something is more important than safety And, maybe rust is a poor choice because the language encourages layering hidden complexity and architecture astronauting.
- dureuill 3y ago
  Because gov agencies say so? Also, memory safety vulnerabilities is the largest class of vulnerability by count today by a large margin (70% of the total) and cost a lot of money to bigger companies. As changing language stacks also cost a lot of money, there needs to be a strong incentive to do so. Getting memory safety without compromising applicability to the lowest levels of the stack is one such incentive. Rust also doesn't have a lot of drawbacks, from my experience (professional use for years, coming from C++) and from recent reports from Google[1] (in particular, the learning curve steepness[2] and productivity penalty[3] are overstated). [1]: https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html https://opensource.googleblog.com/2023/06/rust-fact-vs-ficti... [2]: Anecdotally, these ramp-up numbers are in line with the time we’ve seen for developers to adopt other languages, both inside and outside of Google. (Same report) [3]: Overall, we’ve seen no data to indicate that there is any productivity penalty for Rust relative to any other language these developers previously used at Google. (Same report)
- SkiFire13 3y ago
  > If the first priority is always memory safety, then rust should not have `unsafe` keyword. You can't have a system programming language without some unsafe layer because eventually you will have to interface with either the OS or a library written in another language and that's unsafe. Even languages like Java and C# have unsafe escape hatches for situations like these.
  - throwawaymaths 3y ago
    It seems then rust's first priority is "being a systems programming language", with memory safety being at best second.
- xcdzvyn 3y ago
  Okay yes, the ability to print to stdout, an ultimately unsafe operation, is more important than upholding Rust's ideal of an entirely safe programming language.
- beltsazar 3y ago
  > Why should the first priority be memory safety? Because it's easy for beginners (and even experts) to create a memory safety bug, which is more critical than most bugs. > If the first priority is always memory safety, then rust should not have `unsafe` keyword. Err.. I suppose you don't fully understand how memory safety in Rust can be achieved. Every safe abstraction (function, trait, etc.) depends on unsafe code, either directly or transitively. What's the difference between a safe function and an unsafe one, then? A safe function won't violate memory safety, no matter what combination of arguments passed to it.
  - kibibu 3y ago
    Whether first priority is memory safety depends on a great many things about the software being created.
cryptonector 3y ago
Mainly because GC is easier on inexperienced (and, really, all) programmers than linear types.
- pkolaczk 3y ago
  Not really, because it covers only memory while linear types cover all types of resources with a limited lifetime. GC won’t help you with „this operation is valid only within that context”, e.g. you can write to a file only as long as it is open.
- dureuill 3y ago
  [citation needed]. Here's a reference to the contrary[1]: > Overall, we’ve seen no data to indicate that there is any productivity penalty for Rust relative to any other language these developers previously used at Google. [1]: https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html https://opensource.googleblog.com/2023/06/rust-fact-vs-ficti...
  - kaba0 3y ago
    That link is about learning rust. It’s quite obviously true, that you have to actively think/maintain how long each instance lives, which is simply done by the runtime in your place in case of a managed language. In my experience, this is not a big effort at writing new code, but at refactoring/maintenance - as lifetimes are parts of the public APIs even.
    - dureuill 3y ago
      > That link is about learning rust. While this is true for most of the article, I think the quoted sentence is about more general Rust use. > In my experience, this is not a big effort at writing new code, but at refactoring/maintenance In my experience working on the Meilisearch codebase, Rust is the easiest language to refactor, because it catches so many errors at compile time: 1. Most languages lack the `mut` binding modifier that allows to warn when the binding does not need to be mutable (catching errors when part of the code hasn't been updated) 2. Most languages lack exhaustive initialization, destructuring and matching, that catch pretty much all the situations where a new field has been added to a struct. 3. Let's not speak about languages with null, or without static typing Having more type information (including lifetimes) makes refactorings easier, not harder. I concede it causes a bit more boilerplate but that's not the bottleneck when writing code.

throwawaymaths 3y ago

Why should the first priority be memory safety? If the first priority is always memory safety, then rust should not have `unsafe` keyword. Existence of `unsafe` implies that, even rust, something is more important than safety And, maybe rust is a poor choice because the language encourages layering hidden complexity and architecture astronauting.

dureuill 3y ago
Because gov agencies say so? Also, memory safety vulnerabilities is the largest class of vulnerability by count today by a large margin (70% of the total) and cost a lot of money to bigger companies. As changing language stacks also cost a lot of money, there needs to be a strong incentive to do so. Getting memory safety without compromising applicability to the lowest levels of the stack is one such incentive. Rust also doesn't have a lot of drawbacks, from my experience (professional use for years, coming from C++) and from recent reports from Google[1] (in particular, the learning curve steepness[2] and productivity penalty[3] are overstated). [1]: https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html https://opensource.googleblog.com/2023/06/rust-fact-vs-ficti... [2]: Anecdotally, these ramp-up numbers are in line with the time we’ve seen for developers to adopt other languages, both inside and outside of Google. (Same report) [3]: Overall, we’ve seen no data to indicate that there is any productivity penalty for Rust relative to any other language these developers previously used at Google. (Same report)
SkiFire13 3y ago
> If the first priority is always memory safety, then rust should not have `unsafe` keyword. You can't have a system programming language without some unsafe layer because eventually you will have to interface with either the OS or a library written in another language and that's unsafe. Even languages like Java and C# have unsafe escape hatches for situations like these.
- throwawaymaths 3y ago
  It seems then rust's first priority is "being a systems programming language", with memory safety being at best second.
xcdzvyn 3y ago
Okay yes, the ability to print to stdout, an ultimately unsafe operation, is more important than upholding Rust's ideal of an entirely safe programming language.
beltsazar 3y ago
> Why should the first priority be memory safety? Because it's easy for beginners (and even experts) to create a memory safety bug, which is more critical than most bugs. > If the first priority is always memory safety, then rust should not have `unsafe` keyword. Err.. I suppose you don't fully understand how memory safety in Rust can be achieved. Every safe abstraction (function, trait, etc.) depends on unsafe code, either directly or transitively. What's the difference between a safe function and an unsafe one, then? A safe function won't violate memory safety, no matter what combination of arguments passed to it.
- kibibu 3y ago
  Whether first priority is memory safety depends on a great many things about the software being created.

cryptonector 3y ago

Mainly because GC is easier on inexperienced (and, really, all) programmers than linear types.

pkolaczk 3y ago
Not really, because it covers only memory while linear types cover all types of resources with a limited lifetime. GC won’t help you with „this operation is valid only within that context”, e.g. you can write to a file only as long as it is open.
dureuill 3y ago
[citation needed]. Here's a reference to the contrary[1]: > Overall, we’ve seen no data to indicate that there is any productivity penalty for Rust relative to any other language these developers previously used at Google. [1]: https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html https://opensource.googleblog.com/2023/06/rust-fact-vs-ficti...
- kaba0 3y ago
  That link is about learning rust. It’s quite obviously true, that you have to actively think/maintain how long each instance lives, which is simply done by the runtime in your place in case of a managed language. In my experience, this is not a big effort at writing new code, but at refactoring/maintenance - as lifetimes are parts of the public APIs even.
  - dureuill 3y ago
    > That link is about learning rust. While this is true for most of the article, I think the quoted sentence is about more general Rust use. > In my experience, this is not a big effort at writing new code, but at refactoring/maintenance In my experience working on the Meilisearch codebase, Rust is the easiest language to refactor, because it catches so many errors at compile time: 1. Most languages lack the `mut` binding modifier that allows to warn when the binding does not need to be mutable (catching errors when part of the code hasn't been updated) 2. Most languages lack exhaustive initialization, destructuring and matching, that catch pretty much all the situations where a new field has been added to a struct. 3. Let's not speak about languages with null, or without static typing Having more type information (including lifetimes) makes refactorings easier, not harder. I concede it causes a bit more boilerplate but that's not the bottleneck when writing code.