3 ms·

That string situation in Rust sounds like a lot of cognitive load. I wonder why can a language like Nim (which competes with Rust) have such wonderful dev ux wh

• xrisk 6y ago
  Just a guess but probably because Nim uses a garbage collector and probably doesn't make the same memory safety guarantees that Rust does.
  • nimmer 6y ago
    The garbage collector is optional and Nim is memory safe. Just like Rust, you can unsafe structures when using libraries in C/C++.
• wchar_t 6y ago
  Each string in Rust has a specific purpose. OsString, for instance, is for storing data which might be in, say, UTF-16 instead of UTF-8.
• dpbriggs 6y ago
  Rust prefers explicit, deal-with-the-complexity types. The OP lumped ownership-related types (String/&str) and the nightmare that is filepath encodings (OsString/OsStr). The first case is related to ownership/borrowing as these concepts are fundamental in systems languages. The second case is a hint that filepaths are more complex than a single string type can represent.
• jcranmer 6y ago
  There's two separate issues in play here: The first is the distinction between "owned" (i.e., heap-allocated) and "borrowed" (types). Arguably, there could have been better language support for this to fix this issue. The second is the fact that the underlying OS rules for strings and paths do not conform to any sane string requirements on most systems. If you collapse this into normal strings, then you end up with situations where you can't interact with your OS properly.