News for hackers. Stuff that matters.
Re:How I got involved in the Rust community by elcritch on Friday December 09, 2022 @03:36PM (#33926182)
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.

Re:How I got involved in the Rust community by steveklabnik on Friday December 09, 2022 @03:40PM (#33926223)
I have never used Arc<T>/Rc<T> in my embedded work, and rarely in my non-embedded work.
Re:How I got involved in the Rust community by elcritch on Friday December 09, 2022 @04:01PM (#33926422)
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.
Re:How I got involved in the Rust community by estebank on Friday December 09, 2022 @04:18PM (#33926558)
For what is worth, I rarely need to use Arc or RefCell, but I also rarely write complex async code where it is more prevalent.
Re:How I got involved in the Rust community by robocat on Friday December 09, 2022 @05:23PM (#33927190)
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.
Re:How I got involved in the Rust community by steveklabnik on Friday December 09, 2022 @05:32PM (#33927277)
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.

Re:How I got involved in the Rust community by zozbot234 on Friday December 09, 2022 @05:21PM (#33927161)
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.
Re:How I got involved in the Rust community by surajrmal on Friday December 09, 2022 @06:44PM (#33928040)
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.