I’ll preface this by saying I’m working my way through the Rust book, too–just a bit further along–so don’t take my word as gospel.

This exact scenario is what the ? operator was designed for: returning early with the Err if one is received^[1], otherwise unpacking the Ok. As you’ve discovered, it’s a common pattern, so using the ? operator greatly cuts down on the boilerplate code. If you wanted to do the equivalent of you have here (panicking instead of returning the Err for it to potentially be handled in calling code, albeit without your custom panic messages^[2]) you could achieve this with unwrap() instead of ?:

let html_content_text = reqwest::blocking::get(&permalink).unwrap().text().unwrap();

Both of these will be covered in chapter 9.

If you want to avoid those constructs until later, the only thing I’d say is that some of the intermediate variables seem unnecessary since you can match on the function call directly:

fn get_document(permalink: String) -> Html {
        let html_content = match reqwest::blocking::get(&permalink) {
            Ok(response) => response,
            Err(error) => panic!("There was an error making the request: {:?}", error),
        };

        let html_content_text = match html_content.text() {
            Ok(text) => text,
            Err(error) =>
                panic!(
                    "There was an error getting the html text from the content of response: :{:?}",
                    error
                ),
        };

        let document = Html::parse_document(&html_content_text);

        document
    }

You could also eliminate the final let statement and just stick the parse_document call at the end, but that’s a matter of preference–I know having an intermediate variable before a return can sometimes make debugging easier.

As for whether you should build something now or wait till you learn more–go with your gut! The most important thing is that you stay actively engaged with the material, and many people find diving into projects as soon as possible helps them learn and stay motivated. You could also use rustlings and/or Rust by Example as you go through the book, which is what I’ve been doing (specifically rustlings). It’s not as stimulating as writing a project from scratch, but it does let you write some relevant code. And if you’re not already, I highly recommend using the Brown version of the Rust Book which includes interactive quizzes sprinkled throughout. I’ve found them particularly helpful for understanding the quirks of the borrow checker, which is a topic it continues to revist throughout the book.

For someone only on chapter 7, this is ok. I would not call it idiomatic but you have not gotten to the Error Handling in chapter 9 yet. I would probably hold on getting feedback on error handling until you have gotten to that point.

But the TLDR of it is rust has two forms of errors, unrecoverable errors in the form of panic and recoverable ones in the form of returning a Result. In this case you have opted for panicking which IMO is the wrong choice for something that is expected to fail - and http requests and parsing external data is expected to fail (even if only some of the time). Networks fail all the time, servers go down, send back wrong responses and many other things.

Do you really want to crash your program every time that happens? Probably not - at least not at this level. Instead you likely want to return an error from this function and let the caller deal with it instead as they will likely have more context as to what to do with it rather than in the leaf functions of where the error originates.

But all that is probably for once you have read through chapter 9. For now it is good to know that when you have the pattern

match foo {
    Ok(value) => value,
    Err(err) => panic!("it broke! {}", err),
}

You can generally replace that with a call to expect instead:

foo.expect("it broke")

Or just unwrap it if you dont need to add more context for what ever reason.

This will work in general. One point of improvement: right now, if the request fails, the panic will cause your whole program to crash. You could change your function to return a Result<Html, SomeErrorType> instead, and handle errors more gracefully in the place where your function is called (e.g. ignoring pages that returned an error and continuing with the rest).

Look into anyhow for an easy to use error handling crate, allowing you to return an anyhow::Result<Html>

You can use expect on Options and Results to extract the value and panic on Error in the same line (https://doc.rust-lang.org/std/result/enum.Result.html#method.expect).

let html_content = reqwest::blocking::get(&permalink).expect("the request should succeed");

You can also use unwrap if you don’t need a custom message. The ? operator is definitely the most compact way of handling errors, and for good reason because the rust developers want people to use it. Once you learn that the code will become somewhat smaller.