Even for embedded and other systems programming context automatic memory management via ref-counting systems can perform as well or sometimes even better. I found non-atomic ref-counting to be fine for embedded. For truly small programs I'd rely more on compile time computations which Rust isn't actually great at vs Nim or Zig, or a bunch of others.
Actually both C++ and Rust tend to make heavy use of reference counting via `std::shared_ptr<T>` and `Rc<T>/Arc<T>`, respectively. Personally I think that while Rust's borrow checker is nice for some cases and does encourage fast/efficient memory usage, it's also overkill vs automatic memory management for even most system or real-time programming. Especially as compilers get better and can remove 90% of the reference counting spots.
Ah true, I probably overstate the amount of Arc<T>/Rc<T> in Rust code. C++ uses shared_ptr<T> a lot in the code I've been dealing with lately, so maybe its biased me. Though it's partly up to the skill/experience of the programmer too.
And Steve said, "Let there be borrowing," and there was borrowing. And Steve saw that the borrowing was good.”. Tongue-in-cheek. My guess is that your experience and skills perhaps can’t be projected on to the average developer.
Nah. As the sibling says, these types do heap allocation, and a lot of embedded programs simply don't have a heap.
As esteban says, these types do get used more often in async code, which I don't write a ton of at the moment.
But more importantly, I think that if a beginner tries to use arc/rc to "get around the borrow checker" it introduces even more pain. It's not a beginner's tool, it's a possible misleading path. I left a comment a few years back with a practical example here; while the root cause isn't refcounting, look at how much ceremony they add https://news.ycombinator.com/item?id=24992537
If we were talking about clone, however, that would be a different story: clone is often a great tool for beginners who are struggling with a design that fits into what Rust wants.
And even then, the comment didn't qualify as "beginner code" or "expert code": it said that Rust programs generally "make heavy use of reference counting" and that's simply not my experience, nothing more, nothing less. Not only with my own code, but code I see others write, and libraries that I and others use. YMMV, as always.
Rc/Arc requires allocation, which limits its usefulness for embedded programming. It may become more useful once local allocators get stabilized, which would mean allocations can be made even absent a general heap.
Agreed, it's easy to avoid if you architect your code to avoid sharing state, or stick to only sharing state with children that will always be outlived by the parent.
Actually both C++ and Rust tend to make heavy use of reference counting via `std::shared_ptr<T>` and `Rc<T>/Arc<T>`, respectively. Personally I think that while Rust's borrow checker is nice for some cases and does encourage fast/efficient memory usage, it's also overkill vs automatic memory management for even most system or real-time programming. Especially as compilers get better and can remove 90% of the reference counting spots.