4 ms·

A language has a paved road, and when you go off of that road you are key with extreme annoyance and friction every step of the way. You’re telling people to j

A language has a paved road, and when you go off of that road you are key with extreme annoyance and friction every step of the way. You’re telling people to just ignore the paved road of Rust, which is bad advice.

dewbrite 3y ago
I strongly disagree that smart pointers are "off the paved road". I don't even care to make specific arguments against that notion, it's just a terrible take.
gary17the 3y ago
No, not really. Firstly, there is no significant "friction" to using Rust smart pointers and internal mutability primitives, as those constructs have been added to Rust for a reason: to solve certain borrow checker edge cases (e.g., multiply interconnected data structures), so they are treated by the Rust ecosystem as first-class citizens. Secondly, those constructs make a pretty good educational tool. By the time people get to know Rust well enough to use those constructs, they will inevitably realize that mastering the Rust borrow checker is just one book chapter away to go through out of passion or boredom.
- wredue 3y ago
  I find quite a lot of friction in being demanded to understand all of the methods, what they do, when you’d use them, why you’d choose one over another that does a slightly different thing, but maybe still fits. The method documentation alone in reference counting is more pages than some entire programming languages. That’s beside the necessary knowledge for using it.
  - gary17the 3y ago
    I don't think it's necessary to understand every single `Rc<T>` method[1] to use Rust smart pointers to learn Rust. Perhaps try a different learning resource such as "Rust By Example"[2], instead? [1] https://doc.rust-lang.org/std/rc/struct.Rc.html https://doc.rust-lang.org/std/rc/struct.Rc.html [2] https://doc.rust-lang.org/rust-by-example/std/rc.html https://doc.rust-lang.org/rust-by-example/std/rc.html
Groxx 3y ago
It's telling people to avoid the famously hard meme-road. Mutexes and reference counting work fine, and are sometimes dramatically simpler than getting absolutely-minimal locks like people seem to always want to do with Rust.
rcxdude 3y ago
Reference counting and locks often is the easy path in Rust. It may not feel like it because of the syntax overhead, but I firmly believe it should be one of the first solutions on the list, not a last resort. People get way too fixed on trying to prove to the borrow checker that something or another is OK, because they feel like they need to make things fast, but it's rare that the overhead is actually relevant.
- 12_throw_away 3y ago
  Yes! Thank you! Dunno what it is about Rust that makes everyone forget what premature optimization is the root of all of.
  - bombela 3y ago
    The zero cost abstraction is so tantalizingly close enough to reach! I tell everybody to .clone() and (a)rc away and optimize later. But I often struggle to do that myself ;)
- int_19h 3y ago
  If it's syntactically messy, though, it's not really the easy path. Ergonomics matter just as much as semantics. I do think that a superset of Rust that provided first-class native syntax for ARC would be much more popular.

dewbrite 3y ago

I strongly disagree that smart pointers are "off the paved road". I don't even care to make specific arguments against that notion, it's just a terrible take.

gary17the 3y ago

No, not really. Firstly, there is no significant "friction" to using Rust smart pointers and internal mutability primitives, as those constructs have been added to Rust for a reason: to solve certain borrow checker edge cases (e.g., multiply interconnected data structures), so they are treated by the Rust ecosystem as first-class citizens. Secondly, those constructs make a pretty good educational tool. By the time people get to know Rust well enough to use those constructs, they will inevitably realize that mastering the Rust borrow checker is just one book chapter away to go through out of passion or boredom.

wredue 3y ago
I find quite a lot of friction in being demanded to understand all of the methods, what they do, when you’d use them, why you’d choose one over another that does a slightly different thing, but maybe still fits. The method documentation alone in reference counting is more pages than some entire programming languages. That’s beside the necessary knowledge for using it.
- gary17the 3y ago
  I don't think it's necessary to understand every single `Rc<T>` method[1] to use Rust smart pointers to learn Rust. Perhaps try a different learning resource such as "Rust By Example"[2], instead? [1] https://doc.rust-lang.org/std/rc/struct.Rc.html https://doc.rust-lang.org/std/rc/struct.Rc.html [2] https://doc.rust-lang.org/rust-by-example/std/rc.html https://doc.rust-lang.org/rust-by-example/std/rc.html

Groxx 3y ago

It's telling people to avoid the famously hard meme-road. Mutexes and reference counting work fine, and are sometimes dramatically simpler than getting absolutely-minimal locks like people seem to always want to do with Rust.

rcxdude 3y ago

Reference counting and locks often is the easy path in Rust. It may not feel like it because of the syntax overhead, but I firmly believe it should be one of the first solutions on the list, not a last resort. People get way too fixed on trying to prove to the borrow checker that something or another is OK, because they feel like they need to make things fast, but it's rare that the overhead is actually relevant.

12_throw_away 3y ago
Yes! Thank you! Dunno what it is about Rust that makes everyone forget what premature optimization is the root of all of.
- bombela 3y ago
  The zero cost abstraction is so tantalizingly close enough to reach! I tell everybody to .clone() and (a)rc away and optimize later. But I often struggle to do that myself ;)
int_19h 3y ago
If it's syntactically messy, though, it's not really the easy path. Ergonomics matter just as much as semantics. I do think that a superset of Rust that provided first-class native syntax for ARC would be much more popular.