3 ms·
The String and &str thing is a common criticism of Rust, but I feel it's a bit shallow when said without context. Maybe it's just me, but it makes sense when yo
by thegeomaster 9y ago
The String and &str thing is a common criticism of Rust, but I feel it's a bit shallow when said without context. Maybe it's just me, but it makes sense when you consider Rust's ownership semantics (which are a new idea in language design, so you can't really look at how other languages solved issues arising from them).
Basically, when you have the notion of ownership/lifetime in a language, you have to make a distinction between an owned and a borrowed thing. When you pass an owned thing to a function, you give up your ownership of it, and can't use it anymore. When you pass a borrowed thing, you keep the ownership, and the compiler tries to prove that, based on ownership info it has, it lives long enough for the operation to be safe. Just as String and &str are owned-borrowed counterparts, you also have e.g. Vector<u8> and &[u8] (the former is an owned vector, the latter is a read-only, borrowed view into that vector) and many more examples of this dichotomy.
I don't see how this could have been solved in Rust without having those two types.
- deleted 9y ago[deleted]