4 ms·

So I could mark my code unsafe and be able to prototype faster , then later when it's time to ship , remove unsafe and fix the smaller issues ?

hermanradtke 6y ago
One must write structure a program in a way that is compatible with the borrow checker. It would probably require a rewrite to make unsafe code that was purposefully ignoring the borrow checker then pass the borrow checker. Keep working at it. After a while you start to realize the patterns that work. Now, I can prototype in Rust pretty fast.
steveklabnik 6y ago
In theory yes, but in the way you're probably thinking about it, no. Unsafe doesn't turn off checks, it adds features that are unchecked. So you can't just toss in unsafe blocks and get the compiler to let you do whatever you want, you have to actually write different code.
bryanlarsen 6y ago
I don't have much experience, and thus might be wrong, but one thing I've internalized is that it's often better to just use Rc<T> (reference counted smart pointers) or a garbage collector to make forward progress rather than fight the compiler trying to get lifetimes straight. You can make it more efficient later, but it's often not to worth the bother.
- ywei3410 6y ago
  I'm curious at how prevalent this opinion is among Rust developers; it seems to me that it would defeat the point of using Rust at all and go with a strongly-typed GC language.
  - steveklabnik 6y ago
    Personally, I think once you get to a certain place, you don't end up doing this super often. I do think that it's a good idea whenever you feel like you need to do it, and it can help you get enough experience with the language to be able to get over that hump. There are also a lot of nice features in Rust other than the pure absolute runtime efficiency.
    - ywei3410 6y ago
      Thank you — it’s good to know that. Rust is not my first-choice language; which means that I tend to use it when I need something non-trivial and low-level. The problem, of course, is that it colours the experience, so I’m always curious to listen to other experiences. > There are also a lot of nice features in Rust other than the pure absolute runtime efficiency. Certainly! I reread my earlier post and see how it could have been more qualified; what I meant to say was if the burden of the borrow-checker is so high that the user needs to use the ~Rc~ by default /I/ would find it hard to justify Rust for /that/ type of programming over other languages with similar features.
  - estebank 6y ago
    A single well placed Rc<RefCell<T>> can simplify a design immensely, and it is made obvious if it is present in a performance critical path. 99% of the time, though you don't use it because either the design is simple enough not to need to deal with multiple ownership, or the performance requirements make it so that you have to figure out how to avoid it. > it seems to me that it would defeat the point of using Rust at all and go with a strongly-typed GC language. This seems to be a regular comment when talking about Rust (among other "incremental improvement" approaches) and I don't really get it: for 95% of the code things are simple enough that you don't have to think too much about it, the other 5% can either rely on one of the multiple-ownership safe abstractions or use unsafe. To me this framing sounds like "why do I need seat belts, if I fall of a cliff it won't do any good!"
    - ywei3410 6y ago
      The parent comment insinuated that it was used more than 1% of the time; which also mirrored my (brief) time using Rust. I spent long periods of time as a beginner trying to get a good program structure past the borrow-checker only to discard the work, when I realized that certain problems introduced different ownership constraints. Of course, part of that is due to the fact I haven’t spent a prolonged period of time in Rust. I imagine that it would get better with time; hence I was surprised to hear an opinion that used ~Rc~ by default. > To me this framing sounds like "why do I need seat belts, if I fall of a cliff it won't do any good!" I’m sorry that that’s how you read my comment — the languages I tend to use are much higher-level than Rust, like Haskell and Lisp, and I constantly found myself having to restructure my code to deal with memory-management. In particular, I found closures and futures difficult to work with — compared to a higher-level GC language. This experience may or may not be typical; I have few data-points to draw on after all!
- CodesInChaos 6y ago
  I agree. Rc+RefCell or Arc+Mutex and cloning values instead of passing references are much better escape hatches when the borrow checker complains during prototyping than going for unsafe.
ncallaway 6y ago
I think theoretically. Though I have found that the borrow checker often ends up pushing architectural changes on me as I'm fixing things. This might be because I'm just newer with Rust, but I personally would find resolving 30 borrow-checker issues at once to be much more painful that resolving them as I go.
ben-schaaf 6y ago
Sure, if by "smaller issues" you mean a likely redesign of large parts of the codebase. Think of it like writing C code without bothering to free any memory. In C having to free allocated memory manually dictates how data structures are built and how your program flows. Often you have to keep track of extra state in order to free your memory at the right time and if you don't have this in mind from the get-go you're going to write code that leaks a lot of memory or doesn't work. The same is true for rust, but instead of the code leaking or not working it doesn't compile. If you turn those checks off with unsafe you're essentially stuck with an improved C that's just as difficult to prototype in. Systems programming languages are simply not designed for fast prototyping, instead focusing on fast and in rust's case correct code. A GC, dynamic typing, high level library, etc. all help you prototype faster but you're not going to be able to use them to write an OS or a web browser.

hermanradtke 6y ago

One must write structure a program in a way that is compatible with the borrow checker. It would probably require a rewrite to make unsafe code that was purposefully ignoring the borrow checker then pass the borrow checker. Keep working at it. After a while you start to realize the patterns that work. Now, I can prototype in Rust pretty fast.

steveklabnik 6y ago

In theory yes, but in the way you're probably thinking about it, no. Unsafe doesn't turn off checks, it adds features that are unchecked. So you can't just toss in unsafe blocks and get the compiler to let you do whatever you want, you have to actually write different code.

bryanlarsen 6y ago

I don't have much experience, and thus might be wrong, but one thing I've internalized is that it's often better to just use Rc<T> (reference counted smart pointers) or a garbage collector to make forward progress rather than fight the compiler trying to get lifetimes straight. You can make it more efficient later, but it's often not to worth the bother.

ywei3410 6y ago
I'm curious at how prevalent this opinion is among Rust developers; it seems to me that it would defeat the point of using Rust at all and go with a strongly-typed GC language.
- steveklabnik 6y ago
  Personally, I think once you get to a certain place, you don't end up doing this super often. I do think that it's a good idea whenever you feel like you need to do it, and it can help you get enough experience with the language to be able to get over that hump. There are also a lot of nice features in Rust other than the pure absolute runtime efficiency.
  - ywei3410 6y ago
    Thank you — it’s good to know that. Rust is not my first-choice language; which means that I tend to use it when I need something non-trivial and low-level. The problem, of course, is that it colours the experience, so I’m always curious to listen to other experiences. > There are also a lot of nice features in Rust other than the pure absolute runtime efficiency. Certainly! I reread my earlier post and see how it could have been more qualified; what I meant to say was if the burden of the borrow-checker is so high that the user needs to use the ~Rc~ by default /I/ would find it hard to justify Rust for /that/ type of programming over other languages with similar features.
- estebank 6y ago
  A single well placed Rc<RefCell<T>> can simplify a design immensely, and it is made obvious if it is present in a performance critical path. 99% of the time, though you don't use it because either the design is simple enough not to need to deal with multiple ownership, or the performance requirements make it so that you have to figure out how to avoid it. > it seems to me that it would defeat the point of using Rust at all and go with a strongly-typed GC language. This seems to be a regular comment when talking about Rust (among other "incremental improvement" approaches) and I don't really get it: for 95% of the code things are simple enough that you don't have to think too much about it, the other 5% can either rely on one of the multiple-ownership safe abstractions or use unsafe. To me this framing sounds like "why do I need seat belts, if I fall of a cliff it won't do any good!"
  - ywei3410 6y ago
    The parent comment insinuated that it was used more than 1% of the time; which also mirrored my (brief) time using Rust. I spent long periods of time as a beginner trying to get a good program structure past the borrow-checker only to discard the work, when I realized that certain problems introduced different ownership constraints. Of course, part of that is due to the fact I haven’t spent a prolonged period of time in Rust. I imagine that it would get better with time; hence I was surprised to hear an opinion that used ~Rc~ by default. > To me this framing sounds like "why do I need seat belts, if I fall of a cliff it won't do any good!" I’m sorry that that’s how you read my comment — the languages I tend to use are much higher-level than Rust, like Haskell and Lisp, and I constantly found myself having to restructure my code to deal with memory-management. In particular, I found closures and futures difficult to work with — compared to a higher-level GC language. This experience may or may not be typical; I have few data-points to draw on after all!
CodesInChaos 6y ago
I agree. Rc+RefCell or Arc+Mutex and cloning values instead of passing references are much better escape hatches when the borrow checker complains during prototyping than going for unsafe.

ncallaway 6y ago

I think theoretically. Though I have found that the borrow checker often ends up pushing architectural changes on me as I'm fixing things. This might be because I'm just newer with Rust, but I personally would find resolving 30 borrow-checker issues at once to be much more painful that resolving them as I go.

ben-schaaf 6y ago

Sure, if by "smaller issues" you mean a likely redesign of large parts of the codebase. Think of it like writing C code without bothering to free any memory. In C having to free allocated memory manually dictates how data structures are built and how your program flows. Often you have to keep track of extra state in order to free your memory at the right time and if you don't have this in mind from the get-go you're going to write code that leaks a lot of memory or doesn't work. The same is true for rust, but instead of the code leaking or not working it doesn't compile. If you turn those checks off with unsafe you're essentially stuck with an improved C that's just as difficult to prototype in. Systems programming languages are simply not designed for fast prototyping, instead focusing on fast and in rust's case correct code. A GC, dynamic typing, high level library, etc. all help you prototype faster but you're not going to be able to use them to write an OS or a web browser.