Rust's users find the module system even more difficult than the borrow checker. I've tried to figure out why, and figure out how to explain it better, for years now. Never really cracked that nut. The modules chapter of TRPL is historically the least liked, even though I re-wrote it many times. I wonder if they've tried again lately, I should look into that.

> Another example is the trait object (dyn Trait), which allows the client of a trait to decide whether dynamic dispatch is necessary, instead of baking it into the specification of the type with virtual functions.

Here I'd disagree: this is separating the two features cleanly. Baking it into the type means you only get one choice. This is also how you can implement traits on foreign types so easily, which matters a lot.

It also have solved the problem where you ended doing a lot of `public` not because the logic dictated it, but as only way to share across crates.

It should have been all modules (even main.rs with mandatory `lib.rs` or whatever) and `crate` should have been a re-exported interface.

This is somewhat of a stretch: dyn Traits in Rust are sort of like compile time duck typing. OTOH, interfaces in Go and virtual functions in C++ are the same thing.

Unit tests should just test code units. All the external stuff should be mocked or not tested.

The example in the post is a unit test.

It’s good to keep it separate as unit tests are really easy to run and less complicated and much faster. Integration tests are much more complicated and often sort of freeze your code as it locks in the implementation.

It's pretty easy to make testing stuff like "We'll conjure into existence a loopback network server" hermetic and likewise for the Entity Framework trick where it runs tests against a SQLite db even though that's not how your real DB works, it's often good enough. Containers are something which could be hermetic, but I am dubious.

This isn't true. It really depends.

    fn main() -> anyhow::Result<()> {

What Rust does with error handling is give you flexibility. It's true that means you can make a mess. I myself have a TODO on my current codebase where I'm not exactly happy with what I'm doing at the moment overall. But it can also be very elegant, and more importantly, it doesn't force you into one paradigm that many not be good for your needs, but allows you to decide, which is very important in Rust's conceptual space. I wouldn't want to be forced to use the above signature in a no_std context, for example.

I agree, but that's kind of my point - that's all these Rust praise articles are ever showing :).

> But it is meaningless to talk about this without doing comparisons.

Not comparing to other languages/approaches however allows a discussion to stay about Rust and how to make things better instead of yet another fruitless discussion about which language or approach is better in a vacuum. I'm not interested in demonstrating that Rust is better than C++ or vice versa, I'm interested in Rust being good on its own merits.

  pub trait LibraryRepository: Send + Sync + 'static {
      async fn create_supplier(
          &self,
          request: supplier::CreateRequest,
      ) -> Result<Supplier, supplier::CreateError>;

My implementation looks something like this:

    impl LibraryRepository for Arc<Sqlite> {
        async fn create_supplier(
            &self,
            request: supplier::CreateRequest,
        ) -> Result<Supplier, supplier::CreateError> {
            let mut tx = self
                .pool
                .begin()
                .await
                .map_err(|e| anyhow!(e).context("failed to start SQLite transaction"))?;
    
            let name = request.name().clone();
    
            let supplier = self.create_supplier(&mut tx, request).await.map_err(|e| {
                anyhow!(e).context(format!("failed to save supplier with name {name:?}"))
            })?;
    
            tx.commit()
                .await
                .map_err(|e| anyhow!(e).context("failed to commit SQLite transaction"))?;
    
            Ok(supplier)
        }

  #[derive(Debug, Clone)]
  pub struct Sqlite {
      pool: sqlx::SqlitePool,
  }

  1. starts a transaction
  2. delegates to an inherent method with the same name
  3. finishes the transaction

  impl Sqlite {
      async fn create_supplier(
          self: &Arc<Self>,
          tx: &mut Transaction<'_, sqlx::Sqlite>,
          request: supplier::CreateRequest,
      ) -> Result<Supplier, sqlx::Error> {

If I want to write a test using a real database, I can do so, by testing the inherent method and passing it a transaction my test harness has prepared. sqlx makes this really nice.

If I'm testing some other function, and I want to mock the database, I create a mock implementation of LibraryService, and inject it there. Won't ever interact with the database at all.

In practice, my application is 95% end-to-end tests right now because a lot of it is CRUD with little logic, but the structure means that when I've wanted to do some more fine-grained tests, it's been trivial. The tradeoff is that there's a lot of boilerplate at the moment. I'm considering trying to reduce it, but I'm okay with it right now, as it's the kind that's pretty boring: the worst thing that's happened is me copy/pasting one of these implementations of a method and forgetting to change the message in that format!. I am also not 100% sure if I like using anyhow! here, as I think I'm erasing too much of the error context. But it's working well enough for now.

I got this idea from https://www.howtocodeit.com/articles/master-hexagonal-archit..., which I am very interested to see the final part of. (and also, I find the tone pretty annoying, but the ideas are good, and it's thorough.) I'm not 100% sure that I like every aspect of this specific implementation, but it's served me pretty well so far.