5 ms·

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-ty

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!

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!