For context for others who may not have a lot of Rust experience, Rust has two string types, the heap allocated `String` and the 'string slice' `&str`, which is a view of some string data anywhere in memory (possibly on the heap, possibly not). A little more info about these types: http://stackoverflow.com/a/24159933/1256624

At the moment, conversions between them are via explicit method calls, which can result in verbose code when handling them. An explicit conversion is required even for the super-cheap `String` -> `&str` conversion (which is just repackaging the 3 words (length, capacity, pointer) of String into the 2 words (length, pointer) of the &str).

Also, start trying to do pattern matching on Vec<String> vs Vec<str> (and the wide variety of static, ref, etc versions there in) and you end up spending a lot of effort to do what is very basic in most languages that support generic pattern matching.

Try a simple use case, parse a command line argument array via pattern matching in a Rust program.

  string.as_slice() == "foo"

  match std::os::args().as_slice() {
      [] => println!("need more arguments"),
      [ref x, ..] if x.as_slice() == "-h" => print_help(),
      [ref a, ref b] if a.as_slice() == "-f" => write_to_file(b.as_slice())
      args @ _ => println!("unrecognised arguments: {}", args)
  }

- http://doc.rust-lang.org/master/getopts/ - https://github.com/BurntSushi/docopt.rs

I think it gets smoother with practice (as in, with practice you're able to know intuitively when you need .as_slice and when a `ref` is required etc.), but yes, improving the ergonomics will be nice. Dynamically sized types will allow for String to be treated implicitly as a &str in many cases, so, e.g., my_string.trim() will work (it currently requires `my_string.as_slice().trim()`). And there is some loose talk about overloading pattern matching via the same mechanism, which would allow proper pattern matching on String with literals `"..."`.

> support generic pattern matching.

There's some subtlety here, e.g. Haskell doesn't support pattern matching on Data.Vector.Vector or Data.Text.Text (which are some of the closest equivalents to &[T], Vec<T> and String).

That said, easy string manipulation is a high priority feature for me. Non-private data access is a high priority feature for the original commenter. I worry that too many of us have expectations for Rust that are unlikely to be fulfilled.

That's not to say that the Rust team has set too high of barriers, only that we have elevated them to something they aren't. I'm less concerned with what the Rust team is delivering (which so far has been great) than with what people seem to be expecting (which is nothing less than a C++ replacement in all contexts).

This is why Rust will have you juggle String (a string with allocation) and &str (a "string slice"; a view into an allocation elsewhere) all the time.

From the early days of computing, history proves systems programming languages only get replaced when OS vendors push another language on their official tooling.

Apple is now pushing Swift and Microsoft, at very least, dumping C.

So will Mozilla push Rust as part of Firefox OS? If not, which OS vendor will pick it up?

Note this applies also to other "wannabe C++" replacements.

[1] http://contiki-os.org/

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

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.

Strings got re-done like ~2 months ago, so don't feel too bad ;)