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, 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.
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
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.
Then again, maybe one would want such things to slow down development
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.
It can also be painlessly integrated into Node.js programs as native modules and interoperability makes a Rust + Node combo a perfect mix for many use cases.
There are some very well solved problems and I don’t think Rust should hide the fact that you can also rely on those. The idea of a cookbook is to solve common problems — and sometimes the easier way to do this is to use an battletested external dependency.
In Python it is often said that stdlib is where modules go to die, and dependency management in Rust is a particularly different experience to most other languages. A good example of why keeping the standard library lean can be a good idea in the long term would be datetime handling in Java: https://stackoverflow.com/questions/12032051/differences-bet...
We can’t just take control of a project just because it’s popular, that’s not really how open source works.
A similar resource that focuses more on the language and standard library is Rust by Example:
If you need something simpler than the community's choice and don't want a dependency, roll your own. Otherwise, the ecosystem has you covered.
I will admit that I don't understand why Random is its own crate, and not in the standard library, however...
This way of doing things has it's advantages though. People are still coming up with new ways of generating random numbers, and in an external library you can release a major version and remove deprecated functionality without breaking anybody's code.
Cargo, the package management system is very good, and the resulting binary is compiled (therefore you aren’t thrusting 3rd party dependencies on your end users), so there is far less incentive to avoid 3rd party libraries than there might be in Python for example.
Can you parse CLI arguments manually using rust? Of course, but should you?
I see that it starts with random numbers, but when I was learning I got tripped up a bit when trying to generate seeded randoms.
It might take some time to respond to, because this project got really far but not quite across the finish line, and I think the main maintainer has dropped out. We’ll get to it...
See e.g.  for a possible approach.
Once its sorted, I think comparing and contrasting this kind of thing would be amazing though.
In general, Rust hates big balls of intertwined mutable state. And traditional OOP-y UI frameworks are basically giant balls of intertwined mutable state. You can do it, but it’s not great. We’ll see.