To be clear: Rust has quite a few smart pointer types, but because Rust makes regular references completely safe, people just use those a lot of the time. For example, very few functions are written to take `Vec<T>`s (the equivalent of C++'s `std::vector`), because they can simply take slices (`&[T]`) which are just a pointer and a length. Storing a slice in a structure isn't unsafe in Rust, so people do it all the time. The same goes for strings (Rust's `&str` is equivalent to C++'s `std::string_view`). It is also very common to pass references directly into slices, strings, or other data structures rather than copying, allocating, or moving, since it's completely safe to do so. You end up only really requiring explicit smart pointers for recursive data structures, or in very rare cases where you need complex ownership behavior.

Thanks for clarifying. That's good, since I assume using smart pointers is more expensive in Rust than using references, same as in C++.

Reference counted smart pointers are more expensive than regular references in rust, but not as expensive as those in C++: Regular Rc pointers live on a single thread, and so don't have to use atomic increment/decrement like they do in C++. In addition, Rust's support for borrowing means that when passing smart pointers around you typically don't need to increment/decrement the pointer at all - because the compiler statically enforces that the borrowed reference lives for a shorter time than the smart pointer it's borrowed from.

Not only legacy, many hardware vendors provide only C bindings leaving the management of resources to the user.

How many hardware vendors provide any kind of Rust bindings at all? Let's compare like with like.

Maybe a more fair example would be std::fstream from C++, which takes a `char const ` (no size integer) or a `std::string` (a.k.a. string buffer) as constructor arguments. In the most idiomatic C++ possible, the standard library would support two character iterators.

In Rust, the equivalent might be:

  let ioResult = File::open(&Path::new("foo.txt"));

...no unsafe pointers or mandatory allocation necessary (1). Plus you're forced to check your error condition by unwrapping the returned value.

I don't bring that up to pick a nit, but to point out that this is basically the state-of-the-art (well, the char might be paired with a size_t) for passing strings through C++ APIs.

(1) I'm not sure whether Path::new actually allocates, but there's nothing stopping you from implementing a tight-and-fast InPlacePath that works seamlessly.

Both, because you don't need them as often.

Not sure, I used them quite extensively in various projects and tried avoiding raw pointers. The only concern can be some cost of overhead when using them.