Another great book that is completely free and open source. Rust might be a little harder to learn then other languages but you can't deny that it has great resources if you decide to learn it.
Because Rust's type system is so good, auto-generated function signatures are actually pretty useful. However this is one area in which the language is clearly immature.
While a large set of libraries is helpful, I wouldn't let that stop you if you think Rust is a good fit for your problem.
Compared to what? (Asking just out of curiosity.)
Not having good documentation means nobody knows how to use your module without a lot of work reading the code. So modules get documented or they get ignored. Thus, the modules on CPAN you know about and that are commonly used and relied on by other modules are the ones that have good documentation. It's self reinforcing. I imagine in a language that funnels use into a single or small set of idiomatic ways to accomplish most tasks, it might be easier to skimp on documentation and rely on people to fall back on the "obvious" way to things.
Well, as is often said, simple is not easy. :) There's a large effort by the CPAN testers community to run every module (and every new version of it) against a large array of hardware and operating systems[1], and provide automated reporting to the author of any problems.
This is possible because of (and incentivizes) the other great aspect of CPAN and the public modules which are on it, which is a strong culture of good test coverage of modules, and the CPAN clients running all tests and failing to install by default if any tests fail that weren't expected to. It's another wonderful feedback loop, and one not encouraged or discouraged by most languages specifically, so the fact that so many package managers for languages decided not to do so is unfortunate. When you don't start with that as an expectation, turning it on at a later date likely just results in a horrible user experience as a large number of module just fail to install (or at a minimum spew warnings which are confusing) because they are exposing what was previously something only the author saw most the time.
https://hexdocs.pm/elixir/Kernel.html
One thing I really like: Unlike in python docs, on all the function calls and most module headings you can click through to the actual elixir source code and see how the functions work under the hood (via the <\> link). You also get this nearly for free when doing docgen on your own modules (it's one line in setup). Also, the HTML is responsive so it's easy to review your own code when on the toilet, if necessary.
And there are python libraries that are horrible offenders. Perhaps it's a matter of taste or experience, but I found the tensor flow docs to be inscrutable and nearly useless
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...
Then again, maybe one would want such things to slow down development
Obviously, these tools don't solve the problem for you. In the same way that some C++ projects use doxygen without writing doc comments and say "but we have auto-docs!", some Rust projects (the rust compiler libraries and official projects, e.g., cargo, libsyntax, etc.) almost completely lack API docs. They do have books (rustc book and implementors guide, cargo book, etc.) so it isn't that they are completely undocumented, but if you want to use these as libraries, the auto-generated API docs are useless.
It's more about how many concepts you need to be aware of to write something. Garbage collection is a complex topic you can ignore at first, for example. Rust pointer management takes immediate investment. Even freeing pointers you can be lazy about at first. Rust makes it easier to write good code at the cost of making it hard to write bad code.