4 ms·
> I hope you do realize that a good GC is usually faster then refcounting, and comparing it to slow GC's does not prove anything. In idiomatic Rust code, you t
by adwn 10y ago
> I hope you do realize that a good GC is usually faster then refcounting, and comparing it to slow GC's does not prove anything.
In idiomatic Rust code, you typically have very few reference increments/decrements, making it faster and more efficient than both, GC and traditional RC-based approaches.
The reasons for this are that objects are often allocated on the stack, passed by reference (a safe pointer), and directly integrated into a larger structure, requiring fewer heap allocations and very few – if any – refcounted objects. In Rust, unlike C or C++, you can do this safely and ergonomically because Rust enforces clear and well-defined ownership semantics.
- rurban 10y agoI do know rust, their RC problems, their unsafe problems, their concurrency and locking problems and their type system problems. What is problematic is that the rust community does not care about it and still repeats wrong sentences all over. (Besides downvoting, but this just shows how much they don't care to learn)
- steveklabnik 10y agoYou haven't actually demonstrated any problems, just repeated that they exist. Unsubstantiated criticism usually gets downvoted on HN, Rust or not.
- adwn 10y ago> I do know rust, their RC problems, their unsafe problems, their concurrency and locking problems and their type system problems. Please elaborate. In particular, what RC and concurrency problems?