Oddbean

@d05bf930 " I really wish that Rust would just auto-discover tests wherever you happen to put them" You can annotate any function with #[test] and Rust will run it as a test. It doesn't have to be in a test module.

@d05bf930 About modules: I used mod.rs too until I had more than two mod.rs files open in my editor and I lost it. You don't even have to open multiple mod.rs files to be confused. If you have one open in a hidden tab, do you know which mod.rs file this is? I ended up closing mod.rs files quickly after editing them. Then I found about the solution with the file `submod.rs` next to the directory `submod`.

@d05bf930 The first variant with a an inline module is almost only used for tests that you want have in the same file but with namespacing. The second variant is obviously useful to have a file as a module without needing to create a directory if it doesn't have submodules. I explained variant 3 and 4.

@d05bf930 One might ask, why not just put the file `submod.rs` inside the `submod` directory (instead of next to it or `mod.rs` inside it)? Well, that would make having a submodule with the same name (submod::submod) impossible with variant 2! (Not that I would recommend that design) More importantly, it makes expanding from variant 2 to variant 3 very easy! Or actually, it makes variant 3 only an extension of 2.

@d05bf930 So you normally only consider variant 2 for a module. Later on, if you want submodules in that module, you just create a directory next to it with the same name. That's it. mod.rs is legacy for backwards compatibility and inline modules are almost only for tests in the same file. Now that I thought about it, I find it brilliant :P

@d05bf930 To be honest, I am confused. You say that you like the "batteries included" approach and yet you complain about having too many functions/methods. Yes, the standard library is extensive and I still learn about new functions. But honestly, rustdoc is the best docs tool I have ever seen compared to other languages, especially for navigation. It is a matter of entering "docs.rs/std" in the browser, pressing Shift+s for search and then using the side bar of the picked search result.

@d05bf930 I have to agree that async closures are a pain. And their error messages are misleading. Maybe @536e35c5 could vibe in 🤍 Async Rust is not complete. This is a fact. You might find workarounds for missing features (like the async_trait crate) though. Unrelated to your post, but although async Rust is not complete, I think that the implemented part of async in stable Rust gets unfair criticism. And Rust teams are working on filling the gaps ❤️

@d05bf930 Sorry for my spam. I really enjoyed your post. Some things are presented unfairly, but you are telling your subjective experience. We need more people talking about their experience with Rust to improve this experience for future fellows ❤️ :ferris:

@5150cec1 I think my complaint here is not that there are too many functions/methods, but more that it's hard to discover and remember which functions to use in which circumstances. An easy example: Result<T> has an .ok() method and Option<T> has an .ok_or() method. I am constantly trying to call .ok() on an Option (or .ok_or() on Result) and then getting really confused when it tells me the function doesn't exist.

@d05bf930 Check out this awesome video which talks about transformations between Result and Option: https://www.youtube.com/watch?v=s5S2Ed5T-dc `ok()` gives you the Ok variant as an Option. You loose information about the error. You can't use `ok()` on an Option because you need to specify an error. You need to give it information. Therefore, you can use `ok_or`. But if your error has to be computed (like a String which allocates), then you want that computation to be lazy with `ok_or_else` and only run on None. https://cdn.fosstodon.org/media_attachments/files/111/130/690/663/922/659/original/7596e529390f2955.png