Sorry, that is a bad reading of my comment (which is my fault). Rust strings are in no way preferable to C++ strings (and in some ways worse). Which is a major failing of Rust FOR MY USE CASES.
That is to say, I had huge expectations for Rust, that it did not (yet) meet. It really made me think about what I wanted from a systems language, and what is possible.
Please don't read this as a screed against the future of Rust, just the present, which didn't really enthrall me enough to learn more of vs C++11
Rust strings are in no way preferable to C++ strings
I haven't been following Rust closely, so this is the first I've heard about the string/slice distinction. But I have spent a lot of time trying to remove unnecessary allocations/deallocations/copies from performance-critical, string-heavy C++ code. I use a combination of custom allocators and slice-like objects, but both of these approaches make it a hassle to interact with code using the natural std::string.
A pervasive distinction between strings that manage their own memory and those that don't, along with language and library support to make using them in combination straightforward would be a big win for me.
I think having felt pain with std::string, you would implicitly understand and enjoy working with the two string types in Rust. They do everything it sounds like you've been doing manually and inconveniently in your C++ code.
Agreed. I'd also make an analogy to C++ where you sometimes must hop between std::string and char*'s with ambiguous lifetimes. Not to mention various custom string types that any big app will have (ex. one that internally exploits jemalloc's allocator optimizations (i.e. exposing block overages), or does rope-style allocation, or intern's into a shared table, or whatever).
I ask because I want to know what Rust's pain points are so that I can suggest ways for the devteam to do better. If you have any feedback, please make your voice heard while we still have time to consider it! :)
