
Rust Cookbook - ingve
https://rust-lang-nursery.github.io/rust-cookbook/
======
bibyte
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.

~~~
whatshisface
The Rust documentation is deep but not wide: unlike Python (for example) the
standard library is small, which means that the well-documented area is small.
Almost as soon as you try to get anything done, you will end up reading auto-
generated function signature docs and browsing through the source code of
whatever crate you want to use. This is true for scientific computing and game
libraries, and may not be true for networking which I hear is very well-
developed.

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.

~~~
melling
That's what Perl programmers used to say about Python. It couldn't compete
with the CPAN library.

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.

~~~
dnautics
To be honest, python libraries are wide but the documentation quality isn't
always the best (I could be spoiled)

~~~
cpach
_”documentation quality isn 't always the best”_

Compared to what? (Asking just out of curiosity.)

~~~
4thaccount
In general, I find Perl's CPAN to usually have really good documentation that
surpasses what Python has, even though I prefer Python over Perl nine times
out of ten.

~~~
kbenson
As a full time Perl developer, I've wondered more than once if this is due to
the way the way the language shapes the community. Perl has evolved (out of
necessity) a very strong level of norms and best practices that users are
aware of, and put effort into following (well, _most_ the time, Perl is all
about letting you pull out the shiny weirdness and letting it shine where it
fits well). Module documentation is part of this. A module could implement an
object oriented interface, a procedural interface, _both_ , import function
into the main scope on use, or on request, or any number of weird (and
depending on your point of view wonderful) things.

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.

~~~
4thaccount
I'm not a full-time Perl Dev like you, but do whip up something a few times a
year and it is there when I need it. I'm therefore incapable of properly
replying to your thoughts although it makes sense to me (Perl is so flexible
that you better have good documentation if you make a module and want it
used). My thoughts are more along the lines of how much modules and CPAN are
pushed in general. Most of my Perl books (Ovid's in particular) go into
excruciating detail on publishing packages. It's not a two pager crammed into
an appendix either, but is front and center. The Perl community frequently
hosts challenges to clean up old modules and such. There is even a guy with
the last name of "Anwar" if I recall correctly that is a celebrity in the
community for how many modules he maintains that aren't even his (and he has
also done challenges like making a new pull-request every day for like a
year). That is some real dedication there to making Perl useful. It is one of
the things I really like about the community. I'm a little bit of a language
hobbyist even though I'm still only a novice coder in my mind. Out of all the
languages that I've spent time with (probably 2 dozen) learning superficially,
I'd say Perl ranks towards the top of the spectrum when it comes to focusing
on this. They've evolved a relatively simple and effective system for allowing
users to make, share, and document libraries.

~~~
kbenson
> They've evolved a relatively simple and effective system for allowing users
> to make, share, and document libraries.

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.

1: [http://matrix.cpantesters.org/?dist=Path-
Tiny+0.104](http://matrix.cpantesters.org/?dist=Path-Tiny+0.104)

~~~
4thaccount
Thanks for the helpful replies. I didn't know that.

------
danso
It's been awhile since I've done anything resembling C/C++, and have put off
looking too much into Rust for the moment, but I was surprised at how readable
the examples on CSV processing were: [https://rust-lang-
nursery.github.io/rust-cookbook/encoding/c...](https://rust-lang-
nursery.github.io/rust-cookbook/encoding/csv.html)

------
nukeop
One of Rust's major advantages over C and C++ and a huge reason why I choose
it for new projects that call for a low level language is better learning
resources. Others are better, established tools (like cargo), helpful
community, sane dependency management, and expressive syntax. Even if it
didn't have any of the borrow checking features I'd still use it just for
those reasons alone.

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.

~~~
stochastic_monk
If I wrote a different kind of C++ (not competing for state-of-the-art speed),
I would absolutely use Rust. Package management, versioning, debugging;
everything is just more convenient. It’s not quite as expressive as I’d like,
but that may yet change, too.

~~~
pcwalton
I'm competing for state-of-the-art speed and I use Rust. Libraries like Rayon
are really helpful compared to things like OpenMP, which we wouldn't ship.

~~~
sanxiyn
What's the problem with OpenMP? From a distance, it seemed to be great.

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

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

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

~~~
estebank
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...](https://stackoverflow.com/questions/12032051/differences-between-java-
util-date-and-joda-time-apis)

------
reificator
Where can I go to suggest new "recipes"?

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.

~~~
amelius
I'd like to see an official recipe for using closures as callbacks (for
example in a UI library), where variables in outer scopes are potentially
modified from within the closure.

See e.g. [1] for a possible approach.

[1] [https://gtk-rs.org/docs-src/tutorial/closures](https://gtk-rs.org/docs-
src/tutorial/closures)

~~~
steveklabnik
I’m a bit torn about this one, because it’s not universally clear that this is
the correct way to build these kinds of systems in Rust. GTK has to due to the
constraints of the system it binds to, but there’s a lot of experimentation of
different ways that may be more Rust-y and not have the huge pain points this
approach has.

Once its sorted, I think comparing and contrasting this kind of thing would be
amazing though.

~~~
amelius
What would be an alternative, equally flexible way to handle callbacks?

~~~
steveklabnik
[https://raphlinus.github.io/personal/2018/05/08/ecs-
ui.html](https://raphlinus.github.io/personal/2018/05/08/ecs-ui.html) is an
entry point into the main alternative that’s being explored, see “druid” as a
package that’s an implementation of (an evolution of) these ideas, though it’s
still early days.

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.

~~~
int_19h
Realistically, this is still a necessity, because even if Rust comes up with
its own quality UI frameworks - which takes years, looking at the history of
the ones that we have - some people will still need to integrate with what's
already there.

~~~
steveklabnik
Sure, it's still necessary, but that doesn't mean that it needs to be promoted
as the correct pattern to use in the general case.

------
pducks32
I love all of Rust’s documentation it has really been great to see as I learn
the language. I can pick up a language easy enough but to pick up a language’s
specific idioms is really hard without examples and this resource is great for
that. One issue I have had though is how often the resource is out-of-date in
some sense. Rust 2018 switched how modules were included and I constantly was
confused what the difference was until I learned one was just older (by like a
month). Also error handling is very confusing for me. I used error-chain first
and everything worked but then I heard failure was the way to go yet there are
very few resources on using either idiomatically.

