58 ms·
The key, I think, is to figure out which kinds of Rust patterns are ambitious and efficient if they work, versus patterns that are easy to write and unlikely to
by hathawsh 7y ago
The key, I think, is to figure out which kinds of Rust patterns are ambitious and efficient if they work, versus patterns that are easy to write and unlikely to fail. It's tempting to use references everywhere possible for efficiency, but Rc, Arc, Cell, RefCell, Mutex, and other smart pointer types can get you out of a jam. Sometimes you just have to bite the bullet and clone things until you've figured out a better way.
Looking back at the very first Rust module I wrote, it's actually not half bad. I thought it was bad at the time because I was continuously fighting the borrow checker, but now I see that the borrow checker led me toward fairly idiomatic Rust patterns.
BTW, if you're coming from Javascript or Python, the closest thing to a JS/Python string in Rust is Rc<String> or Arc<String> (depending on whether your code is multithreaded.) I don't want to admit how long it took me to figure that out and I think that little bit of wisdom ought to be featured prominently in the Rust book. :-)
- saagarjha 7y agoI would steer you away from Rc and Arc unless you know you need them.
- hathawsh 7y agoPerhaps. I can think of a couple reasons to steer people away from Rc/Arc: they are less efficient than references and they don't support cyclic garbage collection. On the other hand, Rc/Arc are very helpful for newcomers coming from garbage collected languages and they can be more efficient than cloning. If I asked an employee to convert some high level module to Rust and that employee used a lot of Arcs where they weren't really necessary, I would say that employee had done a reasonably good job.
- pjmlp 7y agoThey are unavoidable with most GUI bindings on Rust, actually it is a plethora of Rc<RefCell<>> across the code.