As a newbie coming into Nim just this very week (with extensive background in C++, Go, & many more):
* I found the "Nim by Example" \+ the manual surprisingly approachable, easy to read and generally "good enough"; also, using the manual as a reference/searching is acceptable (it's good that it's a one-page HTML). * The Gold Standard of package docs for me is [http://golang.org/pkg](http://golang.org/pkg)/ (see e.g.: [https://golang.org/pkg/time](https://golang.org/pkg/time)/ or [https://golang.org/pkg/text/template/)](https://golang.org/pkg/text/template/\)). Others I found more or less OK: Elm's (e.g. [https://package.elm-lang.org/packages/elm/html/latest/Html)](https://package.elm-lang.org/packages/elm/html/latest/Html\)), Rust's, Yeti's (e.g. [http://dot.planet.ee/yeti/docs/latest/yeti.lang.std.html](http://dot.planet.ee/yeti/docs/latest/yeti.lang.std.html)) * In case of Nim, as a newbie, finding stuff in the default stdlib docs is unfortunately tiresome for me. My current thoughts how I think I'd like if this experience was improved: * I'd like it very much if the procs & types were grouped functionally. Either automatically (like in Go docs) if possible/feasible (e.g. by type of first argument?), or by hand by docs authors (like in Elm docs). Especially in the index, it'd be really cool to see the functional groups (possibly collapsible). * Seeing type signatures in the index might be helpful, to differentiate between the dozens of identical add entries, to find the correct one I'm interested in. * It's tiresome for me when I see a dozen funcs with identical name, but only one of them is documented. I need to painstakingly search for the "main one" with docs, by hand. It would be cool if they all were e.g. merged together, so that all type signatures sharing the same docs were listed in a single compact "bullet list", followed by the shared doc. Other than that, reading this thread (esp. the "before" vs. "after") comparison, I realized I'm apparently already a beneficient of the improvements effort by @miran. I really appreciate your work, I found the quality of the _contents_ of the stdlib docs quite good already, seeing the comparison I understand now it's mostly thanks to you - Thank you _so_ much, Good Sir!!!
