I get that, but that makes it less a "Rust Cookbook" and more "here's some high-quality libraries that do common tasks".

I think that's part of the philosophy of Rust, though. The crate system should be robust enough that the most common tasks can be handled by whatever becomes the community's de-facto standard.

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...

Largely because the design wasn't finished in time for the Rust 1.0 release, and they didn't want to commit to the API.

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.

For comparison, here's how it worked out with C++, which now suffered through not one, but (if you count the original C standard library) two iterations of random number generation APIs with significant flaws in them.

http://www.pcg-random.org/posts/cpp-seeding-surprises.html

How does that make it less of a Rust Cookbook? Like a real cookbook, it collects "recipes". You need ingredients to cook those recipes. No cookbook tells you how to grow you veggies from scratch.

It's not a Rust Cookbook, it's a "Rust with libraries" Cookbook. For example, in a cake cookbook, I'd generally expect it to teach me how to make a cake, instead of step one being "buy this cake mix and here's how to bake it after you do that". This isn't to say that this wouldn't be useful, but generally I'd expect an "official Rust Cookbook" to only include the "official" standard library.

Ah, I guess the problem is that Rust standard library is quite barebones compared to some languages such as Python and Java. A fitting name for a book for creating stuff with Rust standard library only would be something like "Coding X from scratch with Rust". I think that the metaphor of cooking captures the feeling of using Rust with libraries just fine; especially since the libraries featured in the Cookbook are hand-selected to be of an "almost blessed" status in the ecosystem.

A Rust cookbook is more like a "grilling with gas" cookbook in that sense.

On the other hand, I expect Python Cookbook to use requests, not urllib.

I agree. I’d also like to see random beeing part of the std crate, but while it isn’t it is not really feasable to roll your own there for any project that isn’t yet another random.

I wouldn't. If there was a "Writing Python in the real world" document, that's where it belongs–but the official documentation should only really use things that come with Python, with at most a shoutout to good third-party solutions.

So in other words, you want the Rust Cookbook to be dogmatic instead of pragmatic. Which of those would be more useful to beginner and intermediate Rust programmers?

Personally, I think it's a lot more useful to teach beginners and intermediate Rust programmers the extent of the standard library than teach them to grab the first library they find for everything–this is something that they can find out themselves when they realize that the standard library doesn't do what they want. Especially when it's coming from an first-party source like this one.

The point of this book isn't to function neither as the tutorial or intro to the language, nor as a language refererence or stdlib API referenece. It's purpose is to collect common tasks and show idiomatic and practical way to do them in Rust. In the process, its purpose is to introduce central libraries in the ecosystem. It sounds that you want it – and maybe the model of developing software in Rust itself? – to be something entirely different than it actually is.