Hacker News Reader

Comment by duped | Hacker News Reader

I don't think Rust is easy to learn, it's has a kind of famously steep learning curve. The tooling is great which helps, but it's not easy for new-ish systems programmers.

View on HN

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.

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.

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

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.

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.

Agreed, python may be a contrived example here. It is possible to pull this off in a few languages where object relocation isn't a problem and mutating a collection during iteration is natural.

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.

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.

Yeah, I have to agree with this. I tried to get my team at my previous work to adopt Rust, and they all pretty much failed to really pick it up. Granted they weren't the most talented group I've worked with.

Every video I've watched on youtube of Rust vs Go makes me think Rust is not a whole lot of fun to write.

It's really frustrating to write, until it isn't. The language lets you be extremely expressive with about the same level of mental overhead as a garbage collected language. Once it "clicks," it's a joy to work with.

The borrow checker and lifetime annotations. It's always the borrow checker and lifetime annotations - otherwise Rust is, IMHO, as readable as (the excellent) Golang.

I've often wondered what it would be like having a variant of Rust that was essentially the same underlying language, but with a garbage collector of some kind instead of a borrow checker and lifetime annotations.

You can approximate this already: forget Rust references (borrow checking + lifetimes; in other words, raw pointers) and start hacking with Rust using its shared ownership (reference-counted) smart pointers, immutable Rc<T>[1], mutable RefCell<T>[2] and the combination of the two[3]. The syntax will, overall, get considerably more dense than Go, but otherwise analogous to Go. Instead of GC cycles, memory will be freed incrementally, immediately when no longer in use.

[1] - https://doc.rust-lang.org/book/ch15-04-rc.html

[2] - https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...

[3] - https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...

That would be pretty close to OCaml.

That's fair. My favorite language so far has been F#, so maybe it's some of that preference sneaking through.

I've tried learning Rust after learning Go, never really got into it. I also know C, C++, Java, Python, PHP, JS, and a couple others (Perl, anyone?) I find Rust syntax too complex, similar to C++ which I also avoid now.

Reply on news.ycombinator.com