Agreed. There's also another aspect at play: to build knowledge one step at a time with this learn-by-doing approach, you have to get learners to write code that's not perfectly idiomatic along the way. You then correct and refine those first drafts as you progress along.
In the case of setters, we get rid of them at the end of that chapter by using the newtype pattern thus guaranteeing that field invariants can't be broken even if you can access them directly.
To be fair, there is no particular backstory. I picked a hermit crab as the book logo since crabs are strongly associated with Rust due to Ferris, Rust's mascot.
I then landed on that style (and the skull) because they looked sick and distinctive. The cover images of many technical books are incredibly dull these days.
Author here!
This is the third chapter of Zero To Production, an in-progress book on API development with Rust.
Chapter 3 is where the actual implementation of our email newsletter project (the driving example) begins.
We take off by copy-pasting the "Hello World!" example on actix-web's website and then we pick it apart to understand what each component is doing (HttpServer, App, Route, actix_rt, etc.).
We slowly reshape it into an health check endpoint and then spend the remaining 60% or so of the article looking at how to write a black-box integration test for it.
I haven't published the entire Chapter 3 - it has been split in two parts to keep the publishing cadence (once every two weeks).
The second half will come out on August 23rd and tackle database migrations, how to check side-effects in integration tests as well as actix-web's extractors. At the end of it we should finally be able to onboard new subscribers to the newsletter via a form.
Author here!
This article started as a short section in Chapter 3 of Zero To Production (https://www.lpalmieri.com/posts/2020-05-24-zero-to-productio...) to give some background on the decision making process I went through when picking the web framework we will be using to develop our email newsletter project throughout the book.
It eventually grew to be so long that it made little sense as part of Chapter 3 itself - I thus decided to publish it as its own article and link it in the introduction to Chapter 3 (hopefully to be released next week!).
In the case of setters, we get rid of them at the end of that chapter by using the newtype pattern thus guaranteeing that field invariants can't be broken even if you can access them directly.