3 ms·

Well, you will probably think I'm crazy, but for me personally, having a couple of decades of C++ experience, learning Rust turned out to be much easier than le

Well, you will probably think I'm crazy, but for me personally, having a couple of decades of C++ experience, learning Rust turned out to be much easier than learning... Swift. Yes, that famed, ultra-modern, great-as-your-first-programming-language Swift. Except for lifetime annotations and the borrow checker, Rust turned out to be much easier for my brain to parse and memorize than Swift, perhaps due to Rust's consistency and predictability and Swift's horrible language construct bloat.

duped 4y ago
Going from C++ to Rust is pretty much the easiest path, since most of the "hard" parts of Rust are just automating stuff you do by hand in C++ anyway. For other languages where people regularly get tripped up on "what's the stack vs the heap?" coming to Rust it's a bit of a different story, ime. Talking about which object "owns" another that a pointer "outlives" what it points to are totally normal parlance for C++ developers and completely foreign to a lot of other folks.
- msbarnett 4y ago
  I don't disagree but that says to me that a lot of the "Rust is hard" narrative is actually "low-level systems programming is hard", eg) domain complexity is being misattributed to the language.
- palmtree3000 4y ago
  I came to rust from the other direction, as it were: from Haskell. There are a lot of similarities! The type systems are similar, with some name changes (sum types -> enums, typeclasses -> traits). Pattern matching is basically the same. Haskell uses (lazy) lists mostly the same way rust uses iterators. Ownership is new, but imposes some of the same requirements that immutability does (no cycles without shenanigans[0]). Rust requires that values are aliasable XOR mutable: Haskell does too (they're always aliasable and never mutable). [0] https://wiki.haskell.org/Tying_the_Knot https://wiki.haskell.org/Tying_the_Knot
  - chakkepolja 4y ago
    For someone who understands C++11, I don't think FP concept _in rust_ will be hard. But someone who understands Haskell, may still find some memory stuff clumsy.
  - duped 4y ago
    The thing is that mutability is a useful and common property used by most programmers. It takes a bit of buy in to be convinced immutability is a good thing that solves bugs. For example: Here's a reasonable program to write in Python (wave hands here, my python is rusty) queue = [root] for node in queue: if !node.visited: # ... visit the node ... node.visited = True for child in node.children: queue.insert(child) Here's that in Rust. let mut queue = VecDeque::new(); queue.push_back(root); for node in &mut queue { if !node.visited { // ... visit the node ... node.visited = true; for child in &mut node.children { queue.push_back(child); } } } This will not compile, at all. You need to do a lot of work to restructure the data structures in Rust to get that reasonable program to run soundly. Now that's a good thing, because this would be invalid in C/C++ too due to iterator invalidation and lifetime issues, but it's the kind of thing that people who haven't seen a block of code segfault due to a `push_back` before would be confused by. It's rather rare for a programmer to need to learn about memory safety when compilers in managed languages just solve it for you, and in other systems languages they assume you already know it (or don't care that you can write unsafe programs). There's just that additional conceptual burden when learning Rust and why programs that seem syntactically correct and safe are forbidden.
    - msbarnett 4y ago
      TBH I'm surprised that even works in Python – modifying a collection you're in the middle of iterating seems like a bad habit to get into in any language. edit: in fact, if you specifically use a deque in Python the way you are in Rust, Python will throw a "RuntimeError: deque mutated during iteration". This is just a bad approach in any language, honestly.
      - 4y ago

duped 4y ago

Going from C++ to Rust is pretty much the easiest path, since most of the "hard" parts of Rust are just automating stuff you do by hand in C++ anyway. For other languages where people regularly get tripped up on "what's the stack vs the heap?" coming to Rust it's a bit of a different story, ime. Talking about which object "owns" another that a pointer "outlives" what it points to are totally normal parlance for C++ developers and completely foreign to a lot of other folks.

msbarnett 4y ago
I don't disagree but that says to me that a lot of the "Rust is hard" narrative is actually "low-level systems programming is hard", eg) domain complexity is being misattributed to the language.
palmtree3000 4y ago
I came to rust from the other direction, as it were: from Haskell. There are a lot of similarities! The type systems are similar, with some name changes (sum types -> enums, typeclasses -> traits). Pattern matching is basically the same. Haskell uses (lazy) lists mostly the same way rust uses iterators. Ownership is new, but imposes some of the same requirements that immutability does (no cycles without shenanigans[0]). Rust requires that values are aliasable XOR mutable: Haskell does too (they're always aliasable and never mutable). [0] https://wiki.haskell.org/Tying_the_Knot https://wiki.haskell.org/Tying_the_Knot
- chakkepolja 4y ago
  For someone who understands C++11, I don't think FP concept _in rust_ will be hard. But someone who understands Haskell, may still find some memory stuff clumsy.
- duped 4y ago
  The thing is that mutability is a useful and common property used by most programmers. It takes a bit of buy in to be convinced immutability is a good thing that solves bugs. For example: Here's a reasonable program to write in Python (wave hands here, my python is rusty) queue = [root] for node in queue: if !node.visited: # ... visit the node ... node.visited = True for child in node.children: queue.insert(child) Here's that in Rust. let mut queue = VecDeque::new(); queue.push_back(root); for node in &mut queue { if !node.visited { // ... visit the node ... node.visited = true; for child in &mut node.children { queue.push_back(child); } } } This will not compile, at all. You need to do a lot of work to restructure the data structures in Rust to get that reasonable program to run soundly. Now that's a good thing, because this would be invalid in C/C++ too due to iterator invalidation and lifetime issues, but it's the kind of thing that people who haven't seen a block of code segfault due to a `push_back` before would be confused by. It's rather rare for a programmer to need to learn about memory safety when compilers in managed languages just solve it for you, and in other systems languages they assume you already know it (or don't care that you can write unsafe programs). There's just that additional conceptual burden when learning Rust and why programs that seem syntactically correct and safe are forbidden.
  - msbarnett 4y ago
    TBH I'm surprised that even works in Python – modifying a collection you're in the middle of iterating seems like a bad habit to get into in any language. edit: in fact, if you specifically use a deque in Python the way you are in Rust, Python will throw a "RuntimeError: deque mutated during iteration". This is just a bad approach in any language, honestly.
    - 4y ago