7 ms·

It is so popular because it elegantly solves a set of problems that plague systems-level programming (use-after-free, dangling pointers, data races). It is so

by llogiq 11y ago

It is so popular because it elegantly solves a set of problems that plague systems-level programming (use-after-free, dangling pointers, data races). It is so controversial because there are system programmers who have lived for so long with those problems that they now refuse their existence.

tomp 11y ago
You're right on the pros but dead wrong (intentionally?) on the cons. The real reasons it's controversial are: (1) it requires what some people consider excessive amount of annotations for borrowed types, resulting in visual noise, (2) it has an overly restrictive memory safety model (e.g. it prevents concurrent modification, even when provably safe), (3) it claims to be (memory) "safe", but requires (see 2) the use of "unsafe" features for the most basic tasks, such as implementing various collections. There is other criticism (e.g. allowing overflows), but I think the above is the most controversial.
- AlisdairO 11y ago
  > (3) it claims to be (memory) "safe", but requires (see 2) the use of "unsafe" features for the most basic tasks, such as implementing various collections. I think this is an interesting one - implementing collections is (IME) the main thing one needs to use unsafe for in rust. Outside of that I barely find myself needing it at all. Unfortunately, collections are also a go-to intro project for a lot of systems programmers, so I can see how it would be easy to get a bad first impression.
- Certhas 11y ago
  The collections criticism is bizarre. How often do you actually have to use "unsafe" in practice? Collections is one example, but it seems to be quite atypical, and not something you'd typically implement yourself. The argument has always been that it reduces the amount of code you have to check for safety manually. Most of it will be checked by the compiler. Have you run into the problem that most of your code is unsafe? I've only started dabbling in Rust for some projects, but I've not had to write a single line of unsafe yet, and don't see where that would change.
  - tomp 11y ago
    > The argument has always been that it reduces the amount of code you have to check for safety manually. No, Rust's argument is that it eliminates memory unsafety. It even says so on it's front page: "guaranteed memory safety". Except that it's not guaranteed. It relies on you trusting code that (supposedly) expert programmers have written, and which has been reviewed hundreds of times. Which is no better than C. I agree that this criticism is mostly a theoretical one; Rust is still a huge improvement (in safety, and probably other areas) over C. But some people (e.g. myself) oppose lies in principle, no matter how well-intentioned they are.
    - Manishearth 11y ago
      > It relies on you trusting code that (supposedly) expert programmers have written, and which has been reviewed hundreds of times. Which is no better than C. This is a vast oversimplification. It relies on you trusting tiny bits of unsafe code which have been carefully reviewed. This is opposed to entire C codebases which need reviewing. It's much, much easier to audit 10 lines of unsafe code than it is to audit an entire application. The vast majority of Rust code is not unsafe.
      - tomp 11y ago
        Exactly. Just as I've written in my post: > Rust is still a huge improvement > Except that it's not guaranteed
        Manishearth 11y ago
        You will never be able to get both 100% guaranteed memory safety and low level control/performance. Opposing it based on principle means that you'll never move on to anything better because a perfect solution doesn't exist. For what it's worth, you can write quite a lot in 100% safe code, such that you have to trust only the standard library. Which is the case for any programming language. So, the argument on the front page is true. It does guarantee memory safety in safe Rust code, as much as possible. It gives you the tools to extend your abstractions with unsafe Rust code, which you need to supply your own guarantees with.
- Manishearth 11y ago
  > the use of "unsafe" features for the most basic tasks, such as implementing various collections. That's pretty much the _only_ place you need when using unsafe, when implementing "basic collections". The point of Rust's unsafe is to be able to use it to design safe abstractions. This is not a con; this is the _point_ of unsafe. (Also, one can argue that implementing a collection is not a basic task. It's taught very early on in courses as a way of teaching pointers, but collections aren't simple in general and especially when it comes to memory management. See also: http://cglab.ca/~abeinges/blah/too-many-lists/book/ http://cglab.ca/~abeinges/blah/too-many-lists/book/) > it prevents concurrent modification, even when provably safe Are you talking about non-lexical borrows here (that will be fixed soon), or about Rust's restrictions in threaded scenarios? You can alleviate some of the threaded restrictions via scoped threads. Most of the non-threaded ones can be fixed (without a performance penalty) using Cell (RefCell for non-Copy types, though there's a slight cost there). I've been programming in Rust for a while now, and this doesn't turn out to be an issue in practice since the regular way of designing code avoids this pretty well. Programming in Rust as if it was C++ leads to these errors a lot more.
  - tomp 11y ago
    > This is not a con; this is the _point_ of unsafe. It's not a con if you consider C; but it most definitely is a con for a language that advertises itself as having "guaranteed memory safety". > Are you talking about non-lexical borrows here (that will be fixed soon), or about Rust's restrictions in threaded scenarios? I'm talking about the fact that the programmer has to write the code/algorithms in such a way that Rust's very limited proof engine can handle them. This means using collections in a limited way - if the API doesn't support something, you can't do it (an example would be, splitting a vector and updating each element by a separate thread - IIRC that used to be a problem, maybe it has been fixed already?). This also means implementing concurrent algorithms using the (limited) API (Cells, Atomics, ...) - although that's probably the preferred way in C as well, I'm guessing even things like CAS can be abstracted away with zero cost while improving safety. I'm curious, though, how would I implement the following: I have multiple threads, and I only care about the last result (i.e. they can all write to the same memory location)? I agree, though, that this is rarely a problem in practice, which is why Rust is an amazing language. The criticism/controversy is mostly coming from outsiders and/or people like me who disapprove of false advertising in principle.

by llogiq 11y ago

tomp 11y ago

You're right on the pros but dead wrong (intentionally?) on the cons. The real reasons it's controversial are: (1) it requires what some people consider excessive amount of annotations for borrowed types, resulting in visual noise, (2) it has an overly restrictive memory safety model (e.g. it prevents concurrent modification, even when provably safe), (3) it claims to be (memory) "safe", but requires (see 2) the use of "unsafe" features for the most basic tasks, such as implementing various collections. There is other criticism (e.g. allowing overflows), but I think the above is the most controversial.

AlisdairO 11y ago
> (3) it claims to be (memory) "safe", but requires (see 2) the use of "unsafe" features for the most basic tasks, such as implementing various collections. I think this is an interesting one - implementing collections is (IME) the main thing one needs to use unsafe for in rust. Outside of that I barely find myself needing it at all. Unfortunately, collections are also a go-to intro project for a lot of systems programmers, so I can see how it would be easy to get a bad first impression.
Certhas 11y ago
The collections criticism is bizarre. How often do you actually have to use "unsafe" in practice? Collections is one example, but it seems to be quite atypical, and not something you'd typically implement yourself. The argument has always been that it reduces the amount of code you have to check for safety manually. Most of it will be checked by the compiler. Have you run into the problem that most of your code is unsafe? I've only started dabbling in Rust for some projects, but I've not had to write a single line of unsafe yet, and don't see where that would change.
- tomp 11y ago
  > The argument has always been that it reduces the amount of code you have to check for safety manually. No, Rust's argument is that it eliminates memory unsafety. It even says so on it's front page: "guaranteed memory safety". Except that it's not guaranteed. It relies on you trusting code that (supposedly) expert programmers have written, and which has been reviewed hundreds of times. Which is no better than C. I agree that this criticism is mostly a theoretical one; Rust is still a huge improvement (in safety, and probably other areas) over C. But some people (e.g. myself) oppose lies in principle, no matter how well-intentioned they are.
  - Manishearth 11y ago
    > It relies on you trusting code that (supposedly) expert programmers have written, and which has been reviewed hundreds of times. Which is no better than C. This is a vast oversimplification. It relies on you trusting tiny bits of unsafe code which have been carefully reviewed. This is opposed to entire C codebases which need reviewing. It's much, much easier to audit 10 lines of unsafe code than it is to audit an entire application. The vast majority of Rust code is not unsafe.
    - tomp 11y ago
      Exactly. Just as I've written in my post: > Rust is still a huge improvement > Except that it's not guaranteed
      - Manishearth 11y ago
        You will never be able to get both 100% guaranteed memory safety and low level control/performance. Opposing it based on principle means that you'll never move on to anything better because a perfect solution doesn't exist. For what it's worth, you can write quite a lot in 100% safe code, such that you have to trust only the standard library. Which is the case for any programming language. So, the argument on the front page is true. It does guarantee memory safety in safe Rust code, as much as possible. It gives you the tools to extend your abstractions with unsafe Rust code, which you need to supply your own guarantees with.
Manishearth 11y ago
> the use of "unsafe" features for the most basic tasks, such as implementing various collections. That's pretty much the _only_ place you need when using unsafe, when implementing "basic collections". The point of Rust's unsafe is to be able to use it to design safe abstractions. This is not a con; this is the _point_ of unsafe. (Also, one can argue that implementing a collection is not a basic task. It's taught very early on in courses as a way of teaching pointers, but collections aren't simple in general and especially when it comes to memory management. See also: http://cglab.ca/~abeinges/blah/too-many-lists/book/ http://cglab.ca/~abeinges/blah/too-many-lists/book/) > it prevents concurrent modification, even when provably safe Are you talking about non-lexical borrows here (that will be fixed soon), or about Rust's restrictions in threaded scenarios? You can alleviate some of the threaded restrictions via scoped threads. Most of the non-threaded ones can be fixed (without a performance penalty) using Cell (RefCell for non-Copy types, though there's a slight cost there). I've been programming in Rust for a while now, and this doesn't turn out to be an issue in practice since the regular way of designing code avoids this pretty well. Programming in Rust as if it was C++ leads to these errors a lot more.
- tomp 11y ago
  > This is not a con; this is the _point_ of unsafe. It's not a con if you consider C; but it most definitely is a con for a language that advertises itself as having "guaranteed memory safety". > Are you talking about non-lexical borrows here (that will be fixed soon), or about Rust's restrictions in threaded scenarios? I'm talking about the fact that the programmer has to write the code/algorithms in such a way that Rust's very limited proof engine can handle them. This means using collections in a limited way - if the API doesn't support something, you can't do it (an example would be, splitting a vector and updating each element by a separate thread - IIRC that used to be a problem, maybe it has been fixed already?). This also means implementing concurrent algorithms using the (limited) API (Cells, Atomics, ...) - although that's probably the preferred way in C as well, I'm guessing even things like CAS can be abstracted away with zero cost while improving safety. I'm curious, though, how would I implement the following: I have multiple threads, and I only care about the last result (i.e. they can all write to the same memory location)? I agree, though, that this is rarely a problem in practice, which is why Rust is an amazing language. The criticism/controversy is mostly coming from outsiders and/or people like me who disapprove of false advertising in principle.