Hi All! Welcome to the Reading Club for Rust’s “The Book” (“The Rust Programming Language”). This is week 1 (the beginning!!).
Have a shot at going through “the reading” and post any thoughts, confusions or insights here
“The Reading”
-
Finish up to Chapter 2: “Programming a Guessing Game”
-
The Book: https://rust-book.cs.brown.edu/title-page.html (the special Brown University version with quizzes etc)
The Twitch Stream
- @[email protected] ran a twitch stream on these chapters which is now on YouTube: https://www.youtube.com/watch?v=ou2c5J6FmsM
- You might prefer watching and listening to that rather than reading the book.
- Be sure to catch future streams (will/should be weekly: https://www.twitch.tv/deerfromsmoke)
What’s Next Week?
- Chapters 3 and 4
- Start thinking about challenges or puzzles to try as we go in order to get some applied practice!
- EG, Advent of Code
- Maybe some basic/toy web apps such as a “todo”
Hmm, not sure I’m entirely with you.
If the argument to
cmpis of an incorrect or incompatible type (where AFAIU the parent object and argument have to be the same type, eg u32), that alone will be surfaced at compile time no?If so, then Ordering is actually relatively trivial. It’s an enum, with variants for each possible outcome of a comparison on orderable variables (eg numbers).
And the output of
cmpis an Ordering type, which is nice for match statements, as, AFAIU, it forces us to address all possible scenarios (each being a variant of the Ordering enum).But the compile time safety will come from basic type checking on the argument to
cmp.Am I off base here?
Oh I was completely wrong.
cmp()takes a number (not Ordering) and returns Ordering. Sorry for bothering you.Pretty sure that’s what this is all about! A safe space to work through the ideas and details without worrying about being wrong. I wouldn’t have understood this better if you didn’t “bother” me and now we (and anyone else reading this presumably) are both better off!