1. C++ uses the equivalent of an Arc in Rust, because it can't tell if that reference will be shared across threads. In Rust you can use an Rc and, if you ever need an Arc, it will tell you.
2. Rust's `&str[..]` is safe, C++'s string_view causes tons of UAFs, so string_view is used much less frequently whereas &str is ubiquitous in rust code. In general you can share stack space in Rust easily, even across threads, which is incredibly powerful.
I would guess that Arc ends up costing nothing on Intel. Intel's aligned load/ stores come with Acquire/Release atomic semantics, so even if you don't need them you don't get a discount. On modern ARM platforms they're very cheap but perhaps not quite free, and realistically there just aren't that many other platforms. So the Arc/Rc difference may make little practical difference.
I think the clear benefit str has is that it's built in from day one. So any code which doesn't use str but should isn't old code it's just bad code. In contrast if you've got a pile of C++ then nothing written before 2017 uses string_view because string_view did not exist, and so then much of what got written after 2017 also didn't use string_view because the old code didn't understand string_view.
I'm not sure I buy that Arc vs Rc won't make a different tbh. I'd have to see some compelling benchmarks, including under contention. I've seen atomics cause cache thrashing, but maybe things have changed? That was also on AMD hardware.
Comments
There's a lot of examples of this sort of thing.
1. C++ uses the equivalent of an Arc in Rust, because it can't tell if that reference will be shared across threads. In Rust you can use an Rc and, if you ever need an Arc, it will tell you.
2. Rust's `&str[..]` is safe, C++'s string_view causes tons of UAFs, so string_view is used much less frequently whereas &str is ubiquitous in rust code. In general you can share stack space in Rust easily, even across threads, which is incredibly powerful.
I would guess that Arc ends up costing nothing on Intel. Intel's aligned load/ stores come with Acquire/Release atomic semantics, so even if you don't need them you don't get a discount. On modern ARM platforms they're very cheap but perhaps not quite free, and realistically there just aren't that many other platforms. So the Arc/Rc difference may make little practical difference.
I think the clear benefit str has is that it's built in from day one. So any code which doesn't use str but should isn't old code it's just bad code. In contrast if you've got a pile of C++ then nothing written before 2017 uses string_view because string_view did not exist, and so then much of what got written after 2017 also didn't use string_view because the old code didn't understand string_view.
I'm not sure I buy that Arc vs Rc won't make a different tbh. I'd have to see some compelling benchmarks, including under contention. I've seen atomics cause cache thrashing, but maybe things have changed? That was also on AMD hardware.