Hacker News Reader

Comment by saagarjha | Hacker News Reader

This is nice, but it looks like some of these rely on third-party dependencies to make the examples trivial. I'm not really sure it's useful to have an example for say argument parsing which is essentially "here's how to use this argument parser from GitHub".

View on HN

I don’t think implementing your own cryptographically secure cross-plattform RNG bindings would be particularily useful. Same goes for JSON serialization, deserialization with the serde crate.

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.

It might be worth making those "official" then, if it's not worth having everyone reimplementing them? If they're the standard in all but name, to the point where official material is referring to them as the preferred way to do things, I don't see why they should remain as third-party dependencies.

In other for their APIs to evolve independently of the compiler's release cycle.

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

Some of these are produced by the rust project itself, but not all.

We can’t just take control of a project just because it’s popular, that’s not really how open source works.

This resource is intended to teach about the crate ecosystem.

A similar resource that focuses more on the language and standard library is Rust by Example:

https://doc.rust-lang.org/stable/rust-by-example/

It's useful for people who want to do argument parsing.

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

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

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.

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.

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.

It is standard practice by the rust core team to implement as little as possible in the core/stdlib and “bless” 3rd party packages that add otherwise necessary functionality. This allows the language to evolve more quickly.

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?

Reply on news.ycombinator.com