4 ms·

Considering "it's written in Rust" is synonymous with "it has been statically guaranteed to not contain a wide class of common bugs that frequently cause severe

Considering "it's written in Rust" is synonymous with "it has been statically guaranteed to not contain a wide class of common bugs that frequently cause severe vulnerabilities", I think it's relatively reasonable for people to advertise when it's been used for a large project. Especially considering how much people like to gripe about its use.

cstrahan 3y ago
All of the above, and also: If it’s written in Rust, the tooling (Cargo; the Rust language server; etc) make it much easier than most other languages to jump in and fix something or add a new feature. I’ve contributed to projects written in Ruby, Python, Java, C#, C++, Haskell and many others, and every Rust project I’ve ever touched has been much easier/quicker to go from `git clone` to PR submitted. That may not be appealing to people who never fix or extend the software they use; for me, as someone who finds bugs and deficiencies in almost everything I lay eyes on, knowing that a piece of software is written in a language that is the least likely to frustrate me and suck up my time when I inevitably have to dive in and tweak something is a huge competitive selling point over similar software written in other languages.
Capricorn2481 3y ago
Doesn't apply to this project, but that can be also read as "it has taken on a class of bugs it wouldn't have been exposed in a GC language, with little benefit." Or even worse, if the app needs to use unsafe, you'd be surprised how many Rust engineers think unsafe somehow "encapsulates" memory bugs inside the block itself. Which is not true. Using unsafe can cause memory issues that bubble up the call stack. I don't feel any guarantees when a product is made in Rust. There are buggy Rust projects
- davidatbu 3y ago
  > [It's not true] that unsafe somehow "encapsulates" memory bugs. I believe this real-life, 4-year, 1.5 million-line-of-code experiment disagrees with you directly [1] > In general, use of unsafe in Android’s Rust appears to be working as intended. It’s used rarely, and when it is used, it’s encapsulating behavior that’s easier to reason about and review for safety. [1] https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html https://security.googleblog.com/2022/12/memory-safe-language...
  - Capricorn2481 3y ago
    I don't think you really understood my comment. unsafe fn create_null_pointer() -> *const u32 { std::ptr::null() } fn main() { let ptr = unsafe { create_null_pointer() }; // Dereferencing the null pointer outside of unsafe code let value = unsafe { *ptr }; println!("Value: {}", value); } This will segfault, and the compiler won't warn you about it, even though an error didn't actually happen until you printed the value in "safe" code What this article is getting at is that the unsafe keyword highlights pieces of code that Google scrutinizes, not that it has functionality that "magically" encapsulates memory bugs. And yes, it's a lot better than C++. But you still need to be aware this can happen and not assume you're safe All unsafe does is shut off the compiler for sections of the code. You can write code in an unsafe block that bubbles outside of the scope of "unsafe."*
    - davidatbu 3y ago
      Ah, I get what you're saying now. When you said > "you'd be surprised how many Rust engineers think unsafe somehow 'encapsulates' memory bugs inside the block itself," you essentially mean: > "you'd be surprised how many Rust engineers think that they can use unsafe without regard as to whether they are maintaining Rust's safety invariants by hand in their unsafe blocks." Yes, I do find that surprising!
foverzar 3y ago
> Considering "it's written in Rust" is synonymous with "it has been statically guaranteed to not contain a wide class of common bugs that frequently cause severe vulnerabilities" No it isn't. It's not like we've been writing too much applications C-code recently and it's not like Rust offers that much fundamental security over e.g. Golang
- DonaldPShimoda 3y ago
  > it's not like Rust offers that much fundamental security over e.g. Golang It absolutely does, while also being more expressive. I suggest reading more of the type system literature before making unfounded claims like this.
  - foverzar 3y ago
    > I suggest reading more of the type system literature Like what, in general? I've been working with variously typed languages of various maturity with stuff like structural typing, null-safety, sealed/enum types, inlined and dto/data types, functional types, various implementations of traiting/inheritance/prototyping, etc for years. Do you have a specific point or did you assume that being vague makes you look mysteriously smart? Honestly, you are acting like all we ever had is JS, C and Rust.
    - DonaldPShimoda 3y ago
      Okay, so you've listed a lot of type system features... which is fine (and exciting!), but not relevant? > Do you have a specific point or did you assume that being vague makes you look mysteriously smart? My point was what I said: you should read the academic literature in this space to understand why Rust is fundamentally safer than languages like Go. It's not just a made-up marketing ploy. The type system is specifically designed to make it very difficult to incur issues with memory, which was Rust's primary goal as a modern systems language. Yes, other languages have fancy features, and some of those features are not in Rust. But the features you mentioned don't specifically relate to memory safety, which was the topic at hand. Most of the features you mentioned are actually just about expressiveness of the type system, but not fundamentally distinct forms of type-checking. Rust's type system is based on earlier work from Cyclone. You can find the various Cyclone papers here: [http://cyclone.thelanguage.org/wiki/Papers/ http://cyclone.thelanguage.org/wiki/Papers/]. Specifically, you'll want to look at the papers concerned with memory safety, which is where the region-based type system was first introduced. > Honestly, you are acting like all we ever had is JS, C and Rust. No, I'm pretty familiar with the landscape of programming languages — it comes with the job! I think you just didn't understand my point, which is probably my fault for not being clearer originally. It happens when I reply from my phone sometimes. Apologies.

cstrahan 3y ago

All of the above, and also: If it’s written in Rust, the tooling (Cargo; the Rust language server; etc) make it much easier than most other languages to jump in and fix something or add a new feature. I’ve contributed to projects written in Ruby, Python, Java, C#, C++, Haskell and many others, and every Rust project I’ve ever touched has been much easier/quicker to go from `git clone` to PR submitted. That may not be appealing to people who never fix or extend the software they use; for me, as someone who finds bugs and deficiencies in almost everything I lay eyes on, knowing that a piece of software is written in a language that is the least likely to frustrate me and suck up my time when I inevitably have to dive in and tweak something is a huge competitive selling point over similar software written in other languages.

Capricorn2481 3y ago

Doesn't apply to this project, but that can be also read as "it has taken on a class of bugs it wouldn't have been exposed in a GC language, with little benefit." Or even worse, if the app needs to use unsafe, you'd be surprised how many Rust engineers think unsafe somehow "encapsulates" memory bugs inside the block itself. Which is not true. Using unsafe can cause memory issues that bubble up the call stack. I don't feel any guarantees when a product is made in Rust. There are buggy Rust projects

davidatbu 3y ago
> [It's not true] that unsafe somehow "encapsulates" memory bugs. I believe this real-life, 4-year, 1.5 million-line-of-code experiment disagrees with you directly [1] > In general, use of unsafe in Android’s Rust appears to be working as intended. It’s used rarely, and when it is used, it’s encapsulating behavior that’s easier to reason about and review for safety. [1] https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html https://security.googleblog.com/2022/12/memory-safe-language...
- Capricorn2481 3y ago
  I don't think you really understood my comment. unsafe fn create_null_pointer() -> *const u32 { std::ptr::null() } fn main() { let ptr = unsafe { create_null_pointer() }; // Dereferencing the null pointer outside of unsafe code let value = unsafe { *ptr }; println!("Value: {}", value); } This will segfault, and the compiler won't warn you about it, even though an error didn't actually happen until you printed the value in "safe" code What this article is getting at is that the unsafe keyword highlights pieces of code that Google scrutinizes, not that it has functionality that "magically" encapsulates memory bugs. And yes, it's a lot better than C++. But you still need to be aware this can happen and not assume you're safe All unsafe does is shut off the compiler for sections of the code. You can write code in an unsafe block that bubbles outside of the scope of "unsafe."*
  - davidatbu 3y ago
    Ah, I get what you're saying now. When you said > "you'd be surprised how many Rust engineers think unsafe somehow 'encapsulates' memory bugs inside the block itself," you essentially mean: > "you'd be surprised how many Rust engineers think that they can use unsafe without regard as to whether they are maintaining Rust's safety invariants by hand in their unsafe blocks." Yes, I do find that surprising!

foverzar 3y ago

> Considering "it's written in Rust" is synonymous with "it has been statically guaranteed to not contain a wide class of common bugs that frequently cause severe vulnerabilities" No it isn't. It's not like we've been writing too much applications C-code recently and it's not like Rust offers that much fundamental security over e.g. Golang

DonaldPShimoda 3y ago
> it's not like Rust offers that much fundamental security over e.g. Golang It absolutely does, while also being more expressive. I suggest reading more of the type system literature before making unfounded claims like this.
- foverzar 3y ago
  > I suggest reading more of the type system literature Like what, in general? I've been working with variously typed languages of various maturity with stuff like structural typing, null-safety, sealed/enum types, inlined and dto/data types, functional types, various implementations of traiting/inheritance/prototyping, etc for years. Do you have a specific point or did you assume that being vague makes you look mysteriously smart? Honestly, you are acting like all we ever had is JS, C and Rust.
  - DonaldPShimoda 3y ago
    Okay, so you've listed a lot of type system features... which is fine (and exciting!), but not relevant? > Do you have a specific point or did you assume that being vague makes you look mysteriously smart? My point was what I said: you should read the academic literature in this space to understand why Rust is fundamentally safer than languages like Go. It's not just a made-up marketing ploy. The type system is specifically designed to make it very difficult to incur issues with memory, which was Rust's primary goal as a modern systems language. Yes, other languages have fancy features, and some of those features are not in Rust. But the features you mentioned don't specifically relate to memory safety, which was the topic at hand. Most of the features you mentioned are actually just about expressiveness of the type system, but not fundamentally distinct forms of type-checking. Rust's type system is based on earlier work from Cyclone. You can find the various Cyclone papers here: [http://cyclone.thelanguage.org/wiki/Papers/ http://cyclone.thelanguage.org/wiki/Papers/]. Specifically, you'll want to look at the papers concerned with memory safety, which is where the region-based type system was first introduced. > Honestly, you are acting like all we ever had is JS, C and Rust. No, I'm pretty familiar with the landscape of programming languages — it comes with the job! I think you just didn't understand my point, which is probably my fault for not being clearer originally. It happens when I reply from my phone sometimes. Apologies.