The siblings are correct but also not precise in a way in which could be misleading. Rust has one built-in string type: str, commonly written &str. This is a s

The siblings are correct but also not precise in a way in which could be misleading. Rust has one built-in string type: str, commonly written &str. This is a sequence of UTF-8 encoded bytes. Rust also has several standard library string types: * String is an owned version of &str. Also UTF-8. * CString/CStr: like String and &str, but null terminated, with no specific encoding * OsString/OsStr: an "os native" encoded string, in practice, this is the WTF-8 spec. And of course, all sorts of user library-created string types. The issue at hand isn't that there's some sort of special string type that Rust can't represent, it's that they have an existing codebase that uses a specific string type, so they're going to keep using that type for compatibility reasons, rather than one of the more usual Rust types. This means they won't have to transcode between the two types.