4 ms·

> Try answering the common beginner question: “How is &String different from &str?” This has nothing to do with strings though - how is &Vec<T> different from

• josephg 3y ago
  > This has nothing to do with strings Sort of. It certainly affects strings, and you can't really use strings without understanding the difference. My point is that its yet another thing in the big bucket of junk you need to learn in order to use rust effectively. Rust is the only language I know of that has separate types for owned strings and a borrowed strings. Its a powerful concept - and its fast and efficient for the computer. But its not "free". The cost is that it makes it harder to learn rust. While we're on the topic - it also really doesn't help that the names of these types in the standard library are super idiosyncratic. String is to Vec<u8> as &str is to &[u8]. You just have to memorise that. How about Path and PathBuf? One of them is like String, and one is like &str. I swear I have to look it up every single time. I think the investment is worthwhile - I adore rust. But as I said, rust feels more like a better C++ than a better C. All the pain is front loaded, with the assumption that you'll eventually write enough software in rust to make the investment worthwhile. Simpler languages like Python or Go get out of your way immediately and let you be productive. I prefer rust, but there's definitely something to be said for that attitude.
  • bobbylarrybobby 3y ago
    Agree that the naming is pretty bad, but ultimately there are like… three or four of these owned/deref pairs you actually have to remember in day to day usage? I do wish they had gone with a consistent naming scheme, but in the grand scheme of things this is one of the more minor things that Rust got wrong.
  • duped 3y ago
    I think I would sum this up with saying that strings are not simple, and there is a delicate balance between making simple things simple and complex things possible without shooting yourself in the foot - both as a user, and as a library designer. Since Rust prefers to have verbosity and correctness over ease, it makes sense to have multiple types to reflect the different requirements of the underlying data. I sympathize with some of the std library verbosity when it comes to strings (and paths) but I don't think it's really a big criticism of why Rust's learning curve is steep. You have the same issues in C++, and doubly so in C because it doesn't help you at all and when you screw up the program crashes. When you use strings in an unmanaged language and need to manipulate them, you do need to understand the underlying consequences of how those strings are defined and stored. Comparing to managed languages like Python and Go is a bit unfair, because they're working in a different domain. Python is a great example of what happens when you try and hide complexity too far from the programmer - the python3 ecosystem fracture took millions of dollars and over a decade to settle - because of the inherent complexity in string representations. > Rust is the only language I know of that has separate types for owned strings and a borrowed strings. C++ and Objective-C (kinda) have different types for owned and referenced strings. C++ in particular has the same requirements as Rust, where referenced strings need to be able to refer to literals and it's not acceptable to make the default allocate.
  • deleted 3y ago
    [deleted]