Oddbean

@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