3 ms·

Why couldn't Rust's developers write "Rust for Dummies"? I feel like you're connecting dots that aren't actually connected. Obviously having more books from dif

by dbaupp 10y ago

Why couldn't Rust's developers write "Rust for Dummies"? I feel like you're connecting dots that aren't actually connected. Obviously having more books from different authors/perspectives is great for Rust, but I don't see, prima facie, why a non-Rust-developer author would do a better job of "Rust for Dummies" than a Rust developer. For one, I would be surprised if a non-"expert" (which is, I presume, why you're so dismissive of Rust developers) could write a book that gives an accurate/useful mental model of Rust: teaching is the true test of one's knowledge about anything. Additionally, people paid to work on Rust and on Rust documentation/teaching materials (i.e. "Rust developers") are the people most regularly interacting with all sorts of beginners, and thus are likely to have great insight into, for instance, the common difficulties people hit, rather than just anecdoata about their own personal experience/background (which is good too, but is only one point of reference for things that people find hard). Rust developers can write beginners books (indeed, the Rust book is designed to be this, and the second edition succeeds better the first, I've heard) just as much as non-Rust-developers can write expert books.

tormeh 10y ago
You're usually best able to explain something just after you learned it yourself. After a while you forget what was difficult about the thing you learned. A C programmer, a Python programmer and a Java programmer should write the book together, with expert insight from a Rust pro.
- dbaupp 10y ago
  I'm not sure I agree with the anecdote in your first paragraph, and indeed I preemptively addressed it in my comment: one's own experience is just one way in which something can be hard to learn, whereas people who are regularly teaching and interacting with beginners have a broader view on what people find hard. My experience is, broadly speaking, good teachers are those that have had a lot of practice teaching their material.
iopq 10y ago
Just look at K&R. It's so... bland and boring. As a 13-year-old I couldn't keep reading it.
curun1r 10y ago
It's probably a "forrest for the trees" problem...the developers of a language will have their perspective colored by low-level implementation details. As an example, I found the explanation of trait objects incredibly confusing when I read the book. They confused the subject by immediately talking about static vs dynamic dispatch of functions, which is really an implementation detail and performance consequence of using them and not a part of what they are logically. An outsider might have started with a simple explanation of what a trait object is (an instance of a trait where the compiler cannot determine the concrete type at compile time) and make that clear before diving into the consequences of choosing to use one in your code.
- dbaupp 10y ago
  The Rust team is lucky enough to have a dedicated person (Steve Klabnik) writing documentation and teaching, who, as previously mentioned, gets to see a lot of the ways in which people struggle to learn Rust and practice different approaches for teaching it. For the most part, the dark corners of the language implementation are filtered from the compiler hackers, through Steve and his experience, into the actual user-facing documentation. I think the specific case you mention was a problem more caused by a desire to have some documentation for 1.0, even if it isn't perfect, rather than just leaving the feature undocumented. That page is originally[1] based on a blog post[2] that is targeting people who want to know how they work internally, and there wasn't much time before 1.0 for feedback, revision and iteration of it (there was one cycle, which improved it in the direction you want, but more is always better). The second edition[3] doesn't have the 1.0 crunch date, and benefits a lot from feedback on the existing teaching material (like yours here) and the extra experience the team has had teaching Rust, so, by all reports, does a much better job. (It doesn't seem to currently have anything about trait objects, but I'm sure it will soon.) [1]: https://github.com/rust-lang/rust/commit/dbccd70a5736fd2e898b446e6c5f3da5d17538c6 https://github.com/rust-lang/rust/commit/dbccd70a5736fd2e898... [2]: http://huonw.github.io/blog/2015/01/peeking-inside-trait-objects/ http://huonw.github.io/blog/2015/01/peeking-inside-trait-obj... [3]: http://rust-lang.github.io/book/ http://rust-lang.github.io/book/
  - steveklabnik 10y ago

by dbaupp 10y ago

tormeh 10y ago

You're usually best able to explain something just after you learned it yourself. After a while you forget what was difficult about the thing you learned. A C programmer, a Python programmer and a Java programmer should write the book together, with expert insight from a Rust pro.

dbaupp 10y ago
I'm not sure I agree with the anecdote in your first paragraph, and indeed I preemptively addressed it in my comment: one's own experience is just one way in which something can be hard to learn, whereas people who are regularly teaching and interacting with beginners have a broader view on what people find hard. My experience is, broadly speaking, good teachers are those that have had a lot of practice teaching their material.

iopq 10y ago

Just look at K&R. It's so... bland and boring. As a 13-year-old I couldn't keep reading it.

curun1r 10y ago

It's probably a "forrest for the trees" problem...the developers of a language will have their perspective colored by low-level implementation details. As an example, I found the explanation of trait objects incredibly confusing when I read the book. They confused the subject by immediately talking about static vs dynamic dispatch of functions, which is really an implementation detail and performance consequence of using them and not a part of what they are logically. An outsider might have started with a simple explanation of what a trait object is (an instance of a trait where the compiler cannot determine the concrete type at compile time) and make that clear before diving into the consequences of choosing to use one in your code.

dbaupp 10y ago
The Rust team is lucky enough to have a dedicated person (Steve Klabnik) writing documentation and teaching, who, as previously mentioned, gets to see a lot of the ways in which people struggle to learn Rust and practice different approaches for teaching it. For the most part, the dark corners of the language implementation are filtered from the compiler hackers, through Steve and his experience, into the actual user-facing documentation. I think the specific case you mention was a problem more caused by a desire to have some documentation for 1.0, even if it isn't perfect, rather than just leaving the feature undocumented. That page is originally[1] based on a blog post[2] that is targeting people who want to know how they work internally, and there wasn't much time before 1.0 for feedback, revision and iteration of it (there was one cycle, which improved it in the direction you want, but more is always better). The second edition[3] doesn't have the 1.0 crunch date, and benefits a lot from feedback on the existing teaching material (like yours here) and the extra experience the team has had teaching Rust, so, by all reports, does a much better job. (It doesn't seem to currently have anything about trait objects, but I'm sure it will soon.) [1]: https://github.com/rust-lang/rust/commit/dbccd70a5736fd2e898b446e6c5f3da5d17538c6 https://github.com/rust-lang/rust/commit/dbccd70a5736fd2e898... [2]: http://huonw.github.io/blog/2015/01/peeking-inside-trait-objects/ http://huonw.github.io/blog/2015/01/peeking-inside-trait-obj... [3]: http://rust-lang.github.io/book/ http://rust-lang.github.io/book/
- steveklabnik 10y ago