[steveklabnik]

Rust has one string type in the language, and three more in the standard library. This boils down to the intersection of “owned vs borrowed” and “Rust native strings vs C native strings,” and you only need the C variants when doing FFI.

[xscott]

I'm (basically) aware of the details (String, &str, OsString, OsStr, CString, CStr, "star" c_char, and probably some others ("star" const i8, &[u8], ???), and you and I have had this conversation a while back when I had a stronger interest in Rust. I'm not sure if you're correcting me, but you're basically confirming what I said.

As for only needing them when you need them, how could it be otherwise? :-)

[akkad33]

One thing I would say is if you're writing a normal Rust application or library and do not care about c interoperability, you could get by without being aware of anything other than the first 2 types. However in Fsharp you are forced to learn about all other ways of doing things, plus how C# does things, because it is almost impossible to do anything useful without interoperating with C# and dotnet

[xscott]

I think any new user would stumble on Path, OsString, and OsStr pretty quickly when working with files and directories. Rust tried really hard to avoid string related errors at runtime by not allowing strings to have invalid data. It's a defensible goal, and the cost is having multiple string types. And then they've got another doubling of types because of their ownership model.

It's not the choice I would make, but my opinion doesn't really matter. Real world strings (UTF-8, WTF-8, UCS-16, arbitrary bytes) don't follow the rules 100% of the time, so you're always going to end up dealing with that complexity at runtime in one place or another. I think you might as well have one simple string type and accept that. This is what Go chose (not that I'm a regular Go user either).

[steveklabnik]

Yes, this is what I was trying to say. Saying “six or seven types” makes it sound far more complex than it actually is.