2 ms·
For me the most distinguishing trait of Rust is that it's value oriented (not handle oriented like pretty much all other popular languages). Once you start thi
by scotty79 2y ago
For me the most distinguishing trait of Rust is that it's value oriented (not handle oriented like pretty much all other popular languages).
Once you start thinking about values (even for simple variables), the space they occupy (how much, Sized vs Sized?, stack, heap), moving them (which would invalidate borrow) it all starts to make sense. Assignment means "move" by default, not "copy" or "copy handle".
Borrow checker is just a sidenote to that, created just to not have to move and clone stuff too much and expressive types are just nice but not unique.
If you approach it as any other language and think in terms of handles you just get annoyed why your handles (pointers) are so clunky and restricted.
Maybe it's just a bit like Git that its interface is easier to understand if you go from inside out. Interface follows what it's doing. It might be frustrating if you come from the opposite direction. From what you want it to do. But all other popular languages do that instead.
- mlsu 2y agoI mean, this is true of any low-level language like C++ or C. Manual memory management. I think it does drive a lot of people nuts who have only ever worked with GC languages. I think your reaction to Rust depends on where you approach it from: Abstract languages: "Ahhh! String, &str, Cow<str>!?" Low-level languages: "How come this isn't compiling? Oh, wow, I wouldn't have caught that. Cool!" I think at this time, there are a lot of people who are getting into Rust from the "top of the stack", so it is their first foray into manual memory management. Many critiques I have seen of Rust is that it is "too complex" for "no good reason." I think those seem superficially valid, especially if you compare Rust with C. "Just don't use after free bro, skill issue" is easy to say if you've only ever worked on a small, short-lived C codebase with one developer on it. Once you start working on a very large codebase with many contributors, people coming and going, "skill issue" is absolutely nonsensical. The borrow checker is about memory safety; but looking at it more broadly, at the sort of ecosystem-level view, it is about constraining individual programmers. Limiting what an individual programmer can do with the memory, and guiding them towards using memory safely/well, with good compiler warnings.