←back to thread

Flattening Rust’s learning curve

(corrode.dev)
451 points birdculture | 9 comments | 13 May 25 22:25 UTC | HN request time: 1.108s | source | bottom
Show context
Animats ◴[14 May 25 00:22 UTC] No.43979394[source]▶
It's like reading "A Discipline of Programming", by Dijkstra. That morality play approach was needed back then, because nobody knew how to think about this stuff.

Most explanations of ownership in Rust are far too wordy. See [1]. The core concepts are mostly there, but hidden under all the examples.

    - Each data object in Rust has exactly one owner.
      - Ownership can be transferred in ways that preserve the one-owner rule.
      - If you need multiple ownership, the real owner has to be a reference-counted cell. 
        Those cells can be cloned (duplicated.)
      - If the owner goes away, so do the things it owns.

    - You can borrow access to a data object using a reference. 
      - There's a big distinction between owning and referencing.
      - References can be passed around and stored, but cannot outlive the object.
        (That would be a "dangling pointer" error).
      - This is strictly enforced at compile time by the borrow checker.
That explains the model. Once that's understood, all the details can be tied back to those rules.

[1] https://doc.rust-lang.org/book/ch04-01-what-is-ownership.htm...

replies(17): >>43979460 #>>43979907 #>>43980199 #>>43981064 #>>43981313 #>>43981587 #>>43981720 #>>43982074 #>>43982249 #>>43982619 #>>43982747 #>>43983156 #>>43984730 #>>43988460 #>>43990363 #>>43996196 #>>44008391 #
codeflo ◴[14 May 25 06:47 UTC] No.43981587[source]▶
That's not explaining ownership, that motivating it. Which is fine. The thing that's hard to explain and learn is how to read function signatures involving <'a, 'b>(...) -> &'a [&'b str] or whatever. And how to understand and fix the compiler errors in code calling such a function.
replies(2): >>43981705 #>>43983434 #
throwaway81523 ◴[14 May 25 07:07 UTC] No.43981705[source]▶
Is it a lot different from std::unique_ptr in C++?

I thought the Rust Book was too verbose but I liked Comprehensive Rust: https://google.github.io/comprehensive-rust/

I felt like I understood the stuff in the book based on cursory reading, but I haven't tried to actually use it.

replies(2): >>43982080 #>>43984403 #
1. fastasucan ◴[14 May 25 08:01 UTC] No.43982080[source]▶
>Is it a lot different from std::unique_ptr in C++?

Is knowing C++ a pre-requisite?

replies(2): >>43983007 #>>43984289 #
2. casey2 ◴[14 May 25 10:55 UTC] No.43983007[source]▶
I would say knowing the useless features of c++ is a pre-requisite for learning rust yes. It's yet another c++ replacement designed by a committee of phds.

You would think they would be smart enough to realize that a language taking X hours to learn is a language flaw not a user flaw, but modern education focuses on specialization talents rather than general intelligence.

replies(2): >>43983070 #>>43983161 #
3. PhilipRoman ◴[14 May 25 11:07 UTC] No.43983070[source]▶
Right but Rust is supposed to be a systems language. We already have dozens of languages that are easy to learn. The whole reason for having compile time memory management is to satisfy the constraints of a systems language...

I don't think it's much harder than learning C or C++ which are the only comparable mainstream languages.

replies(1): >>43984393 #
4. repelsteeltje ◴[14 May 25 11:22 UTC] No.43983161[source]▶
The goal of some languages might be to be easy to learn. But most "system" languages focus on helping design good software, where "good" might mean reliable, maintainable or performant.

Writing good software most often is not easy. The learning curve of a particular language usually is only a modest part of what it takes.

5. ModernMech ◴[14 May 25 13:27 UTC] No.43984289[source]▶
IME teaching students Rust, knowing C++ first actually is a detriment to learning because they have a bunch of C++ habits to unlearn. Those students "fight the borrow checker" much more than the blank slate students, because they have some idea about how code "should" be written.
replies(1): >>43987197 #
6. ModernMech ◴[14 May 25 13:39 UTC] No.43984393{3}[source]▶
I think it's actually easier, thanks to Cargo and the Crates ecosystem. Some of the hardest things for students are just building and linking code, especially third party libraries.

I run two intermediate programming courses, one where we teach C++, and another where we teach Rust. In the Rust course, by the first week they are writing code and using 3rd party libraries; whereas in the C course we spend a lot of time dealing with linker errors, include errors, segfaults, etc. The learning curve for C/C++ gets steep very fast. But with Rust it's actually quite flat until you have to get into borrowing, and you can even defer that understanding with clone().

By the end of the semester in the C++ course, students' final project is a file server, they can get there in 14 weeks.

In Rust the final project is a server that implements LSP, which also includes an interpreter for a language they design. The submissions for this project are usually much more robust than the submissions for the C++ course, and I would attribute this difference to the designs of the languages.

7. zahlman ◴[14 May 25 17:36 UTC] No.43987197[source]▶
Is this still true if they never learned pre-modern C++ and are accustomed to using all the std::foo_ptrs and expecting the rule of 3 (or 5) to be taken care of automatically that way?
replies(1): >>43987830 #
8. ModernMech ◴[14 May 25 18:38 UTC] No.43987830{3}[source]▶
The prereq for my Rust course is Java, but there are three kinds of students who come to me:

1) those who only know java

2) those who know java and were taught C++ by me. The way I teach that course, they are very familiar with pre-modern C++ because we also learn C.

3) those who know java and C++ but they learned it on their own.

It's the last group who has the most trouble. IME the exact issue they struggle with is the idea of shared mutable state. They are accustomed to handing out pointers to mutable state like candy, and they don't worry about race conditions, or all the different kinds of memory errors that can occur and lead to vulnerabilities. They don't write code that is easily refactored, or modular. They have a tendency to put everything into a header or one main.cpp file because they can't really get their head around the linking errors they get.

So when they try to write code this way in Rust, the very first thing they encounter is a borrow error related to their liberal sharing of state, and they can't understand why they can't just write code the way they want because it had been working so well for them before (in their very limited experience).

Pedagogically what I have to do is unteach them all these habits and then rebuild their knowledge from the ground up.

replies(1): >>43987960 #
9. zahlman ◴[14 May 25 18:50 UTC] No.43987960{4}[source]▶
> So when they try to write code this way in Rust, the very first thing they encounter is a borrow error related to their liberal sharing of state, and they can't understand why they can't just write code the way they want because it had been working so well for them before (in their very limited experience).

Ah, well, a shame they didn't see the failing tests for the C++ code first ;)