I wrote this piece hastily, and it really wasn't intended for this broad of an audience — I won't redact the existing wording I still think it's roughly right, but I do regret a lot of it.

Rust's docs are amazing in certain contexts — the book is great, the built-in support for documentation on types/functions/etc. is amazing, and compiling code examples are a very laudable idea.

What I'm speaking to here is more once you get into the broader ecosystem and start using a lot of non-core libraries. Oftentimes I found that the front page docs explaining the basic premise were concise and well-written, but that things got quite a bit harder when you started diving into individual classes and functions (put another way, as you started deviating from the happy path). This doesn't apply everywhere, but often the comments are very minimal and the documentation relies heavily on "types as documentation" in that there's a big list of all the traits and the functions on those traits that are implemented. In many, many cases there's little in the way of detail or examples.

I've written quite a bit of Rust now and have used many of the headliner projects. So far there have been very few crates where I didn't have to resort to eventually checking out the source tree and figuring out how to do some particular thing by examining its source code and test suite. I won't call out any single project in particular, but I found this to be the case in every one of `actix`, `clap`, `diesel`, `error-chain`, `horrorshow`, `hyper` and `juniper`, just to pick a few from the top of my `Cargo.toml` (it also happened with many other libraries). It's great that you can do this and open source is awesome, but ideally I could get by on just documentation, which is what you can do in many other languages.

Unfortunately, read with little context, it sounds like the tone of my piece was intended to crucify, but it's not. It can be simultaneously true that Rust's docs can still use lots of improvement and that the Rust team is doing an amazing job of improving them (there's just a lot of work and a long way to go). Both these facts are true with Rust.

I take documentation bugs seriously. If you did this with any of my crates, please file bugs. My guess is that other crate authors might feel the same, and that they would also appreciate bug reports.

Writing good docs is super hard, because in order to do it well, one must sink themselves entirely into the perspective of someone who is seeking answers. This is hard when you already have the answers.

Will do! For what it's worth, I also had `chan` in dependencies list, but didn't list it above because it's one of the minority where the docs and examples were very good.

More generally, I feel quite bad for complaining about things instead of going in to improve them (through bug reports or patches), but there has to be a balance between making forward progress and stopping to help shore up the tooling. That said, I haven't been doing enough of the latter lately, so I'll make more of an effort.

Don't even know how many times I've had to dig into the python sources to figure out why something wasn't working as intended...

My favorite: I was trying to get memory buffer working for an object (following the official docs) using the C-api and it just didn't work no matter how much I fiddled with it so I go digging through the python sources and find out the fully documented feature I was attempting to use wasn't even implemented. Well, half the PEP was implemented.

I'm probably just funny that way since if I can't figure something out from docs I just go read the sources.

The rust docs are super useful, but not everyone bothers to publish them, and people tend to forget to pit full working examples in them.

Far far far better documentation. The Rust documentation is a mess and difficult to read for many people, but many involved in Rust seem to deny that it is a problem.

We are constantly tweaking the layout of stuff, and have some larger plans on the way as well.

I think because:

a) the general layout feels a bit weird to me. I can't work out which bits are important and which bits aren't. There is no table of contents or similar structure b) as I'm still learning Rust the function signatures are often black magic to me, which adds to the confusion

https://doc.rust-lang.org/std/boxed/struct.Box.html is a good example.

This is a huge page, and it's overwhelming with no table of contents, or without things I probably don't care about collapsed. It is not clear to me how to use Box from this page.

Specifically for Box there is a code example on how to create a Box (great) but no indication of how to use one. Turns out you just use it and it works transparently like T would. Unlike a monad like Option or whatever. I don't know if this is obvious is you're an expert looking at the Struct signature at the top, but it's not obvious to me. It's also not obvious from the module documentation: https://doc.rust-lang.org/std/boxed/.

Then sections are broken down into different implementations against Box. Is that helpful? As a noob I don't know why that matters, I primary want a list of functions that I can interact with.

I see a lot of the function signature contains links, specifically to any other struct / trait / whatever. This is really helpful. It would also be great if there was some way of getting up to speed with parts of the structure I don't understand as well, as Rust has that Scala / Haskell trait of crazy complicated function signatures. I realise putting links on all bits is infeasible, so perhaps that is a documentation page itself, similar to how SQL structures are documented: https://www.sqlite.org/lang_select.html

> Is that helpful? As a noob I don't know why that matters, I primary want a list of functions

Yes, as it lays out the requirements for each one. Not every method is always available; it depends on what’s in the box!

Node is very straightforward:

https://nodejs.org/api/index.html

Python has a library reference and a language reference:

https://docs.python.org/3/library/index.html

https://docs.python.org/3/reference/index.html

All 3 of these pages are blatantly obvious index pages. For Rust, this is where I assume you're supposed to end up (there are way too many links on the "Documentation" page, I'll address this at the end):

https://doc.rust-lang.org/std/index.html

You have to navigate/scroll to see the actual list of modules/types/macros or minimize the "about" section. The first thing that I think I should see on an API docs page is an index with maybe a very short blurb/link in regards to the prelude. If the API reference needs a "How to read this documentation" that is long enough to block you from seeing the index itself, something is wrong. Any user that clicks into an API specification either knows how to read it or knows how to click a link that says "about these docs". If they didn't, they would likely be in the "learning" section. Beyond that, the section has a list of 4 links, 3 of which are anchors (that are both out of order and already listed on the left nav) while the prelude link goes to a completely separate page.

To address the Documentation landing page, you have "Learning Rust" and "References". Learning Rust > The Rust Programming Language and References > Syntax Index effectively both go to the same page. At the bottom you have a "Project Policies". Are those really part of "Documentation"? I generally think of "language" documentation, not "organization" documentation when I see the header. I would expect a documentation landing page to be a lot more minimal and easier on the eyes, similar to:

https://doc.rust-lang.org/nightly/

What that page has in common with almost every other language documentation page that I just visited: Bullet points and/or indentation.

EDIT: I should add that I browsed around various language pages while writing this. To add some context for my opinions, I found the Elm docs to be far and away the easiest to navigate excluding the fact that they don't have links to the source code per method. I made it to their API docs without ever hitting an incorrect link. Julia was similar, but I mis-clicked on the manual rather than the standard library because everything is on the same page and neither section collapses.