4 ms·
Something I find interesting about Rust is that we can do those safe patterns, as long as we're willing to lose some performance. The way I think of it: Rust f
by verdagon 4y ago
Something I find interesting about Rust is that we can do those safe patterns, as long as we're willing to lose some performance.
The way I think of it: Rust forces us to choose between flexibility and zero-cost memory safety.
If we choose zero-cost memory safety (in other words, we don't use Rc or unsafe or large Cells) we can't do things like dependency injection, basic observers, backreferences, many kinds of custom RAII, etc. But we do get speed.
On the other hand, if we allow e.g. Rc into our codebases, we can do these patterns just fine, though there is a performance hit.
The final challenge in learning Rust (IMO) is to figure out when Rc is better, and when we can afford the complexity cost of zero-cost memory safety. I've seen a lot of Rust projects move mountains to avoid Rc, and ironically end up adding more run-time overhead and complexity.
- cranky908canuck 4y ago> On the other hand, if we allow e.g. Rc into our codebases, we can do these patterns just fine, though there is a performance hit. Interesting... I was using one of the Project Euler problems as an exercise for learning Rust; I found that Rc actually improved performance (guess: by eliminating a lot of copies/moves as things went in and out of scope).
- deleted 4y ago[deleted]
- eximius 4y agoMaybe you should have been using more immutable references? But I'm actually curious why the compiler would be making many copies after optimization passes. Release builds or debug builds?
- ridiculous_fish 4y agoIf you try to code Rust like JavaScript by using Rc everywhere, you will quickly run into panics when you try to borrow from a RefCell that a caller has also borrowed from. The limitations of &mut cannot be trivially worked around.
- verdagon 4y agoThat's true, one should not overuse Rc. And the other extreme, avoiding Rc entirely, railroads one into a certain architecture which is good for only some use cases and not others. I like to think the community will someday learn when to use Rc. It had better, lest low-overhead languages with more flexibility like Cone [0] overtake Rust. [0] https://cone.jondgoodwin.com/ https://cone.jondgoodwin.com/
- Rusky 4y agoThe "trivial" equivalent to JavaScript is not RefCell, but plain old Cell, applied at the level of individual fields you want to write to. No panics and no (relative) overhead there. RefCell exists more as a bridge back to the world of &mut, since so much of the ecosystem uses that approach. But if you actually have a good reason to write JavaScript-like data structures (e.g. actual interop with a JavaScript-like language) then it just kind of gets in the way.
- verdagon 4y agoOf course, Cell has its own overhead, which is why using large Cells is often worse than just using Rc. It's also very situational; we often have types which don't work with Cell, and it often doesn't make sense to copy objects in many use cases. It's one of those things that works well in theory, but in practice can fall short.
- Rusky 4y agoThat's totally beside the point here: you can do a mechanical (thus "trivial") translation from JavaScript-like code to Rc+Cell, without ever hitting that overhead. That is, JavaScript-like code simply doesn't do large assignments in the first place. It doesn't directly hold move-only objects that are trickier to use with Cell. If you find yourself hitting those cases, you have left the realm of JavaScript-like code, and entered the realm of manual memory management.
- verdagon 4y ago