
Tour of Rust - richardanaya
https://tourofrust.com/
======
JulianWasTaken
Maybe a bit offtopic, but two minor UX issues hit me the first 15 seconds of
trying to open this; sharing in case someone who maintains this sees and hears
similar minor feedback --

First when I saw the splash screen, and saw it say "Press to Continue", I well
first was confused for a split second on "press what?", then assumed it meant
"click", so I clicked my mouse, then when that didn't work assumed it meant "a
key" so I hit a random key, then when that didn't work, summoned my conscious
brain and figured "well I guess it means click specifically on top of this
link text".

And then once on the next page, glancing at a long list of languages without
really reading the text I said "ok I speak English, guess I should click on
that", only to see the same exact page refresh. "Maybe it's broken?", so I
clicked again. When it didn't work the second time, again, conscious brain
again -- "OK, guess there's a next link somewhere here", and scrolled to the
bottom.

~~~
fold_left
I was caught out by the 2nd one too, I hit "English" expecting to be taken to
the English version of the start of the Tour.

------
swagonomixxx
I'm not sure if I'm the only one that this happens to, but every couple of
months I end up re-learning Rust, and because I don't really have any use of
it in my day to day job (Python and Go, some C++) I end up un-learning it, and
then the cycle continues.

What kind of projects are a best fit for Rust, for those who are experienced
with it? Any recommendations for projects to make Rust stick?

Thanks!

~~~
mamcx
> I don't really have any use of it in my day to day job (Python and Go, some
> C++)

Find one of the most simple utility (probably a CLI) you have and rewrite it.

I have a lot, and find useful to turn some python stuff so is easier to ship
(surely Go work here...)

~~~
LockAndLol
Is it really that easy to write a dirty script with rust? It doesn't seem like
something that's very forgiving nor allows rapidly testing concepts or
prototyping.

Do you personally start writing Rust from the get-go or do you first write
something in some scripting language and then transform it to rust once the
basics work?

~~~
mamcx
> Is it really that easy to write a dirty script with rust?

Eventually.

I struggle, a lot, for the first 3 months of Rust. Not each minute doing rust.
I code in 2-3 other langs, but the slow was pretty obvious.

I think have worked in so many other langs (+12) actually hurt me most. I try
to start with rust like all the rest: Go ahead coding, figure stuff along.

I stop doing like a idiot when I start looking at it as my FIRST lang ever:
read a book, be slowly, PAY attention to what are the concepts "owned",
"move", etc..

Also:

I try to learn with building a relational lang, and develop the routine to
build very small rust projects of a single file. I have done dozens now, and I
start to click to me, and can do a lot of stuff far faster and near python-
speed (when simple and normal).

------
tptacek
This is good, but the string handling stuff should be earlier in the tour,
because Rust's strings are idiosyncratic (whole blog posts have been written
about str vs. String, an issue that doesn't appear in most other languages).
It'd be a nit, but handling strings is one of the most important things you
usually need to know to be productive.

I'd love a version of this for people who know Rust that was just Rust idioms,
similarly explained. I hang out in Slack channel with a bunch of Rust
programmers (because I'm bumbling my way around in Rust as well) and it feels
like there's a _lot_ of communally understood idioms that aren't super
apparent from the Rust Book.

~~~
steveklabnik
We learned the hard way with the Rust book that this is important: one of the
biggest structural changes we made between the first and second editions was
re-orienting the entire book around "how can we get to Strings quickly", and
for exactly the reasons you state.

And yeah, the intermediate area is where things are worst now, for sure. It's
sorely needed.

~~~
richardanaya
I think the big difference between Tour of Rust and the Book is my example
sizes were meant to be as small as possible to demonstrate one concept at a
time. Most of the concepts require no strings at all to explain. Particularly
through the procedural programming chapters.

~~~
steveklabnik
Sure. The issue is, it’s something that people run into very early when they
try to actually write code. They won’t go through the whole Tour before trying
to do so. They certainly don’t with the book :)

Anyway the author should do whatever they want. I’m glad folks other than me
are writing docs! I haven’t managed to actually go through the Tour yet
myself, this is just a riff on the observation made in my parent’s comment.

------
seanalltogether
Every time I try to learn more about Rust, I keep hitting a wall around OOP. I
know Rust takes the stance that composition is better then inheritance, but
I've never found the examples to be very convincing. How do rust developers
deal with complex structs that contain lots of properties and features. For
instance, if I need to create "CustomButton" that means I have to implement
all the Traits from Button, which maybe requires Traits from LayoutView, which
requires Traits from View, etc.... Additionally I need to maintain duplicate
properties of those objects in my Custom Button rather then inheriting from a
Button struct. It sounds like a headache to maintain.

~~~
zozbot234
You can do almost everything with a combination of traits (for interface
inheritance), simple composition and the Deref trait (to auto-forward
unimplemented functions to the contained class). The one feature you're
missing compared to actual OOP inheritance is open recursion, which is a big
footgun more than anything (see: the "fragile base class" problem).

The Rust docs include an in-depth explanation of how Rust relates to
traditional OOP: [https://doc.rust-
lang.org/book/ch17-00-oop.html](https://doc.rust-
lang.org/book/ch17-00-oop.html)

------
blondin
rust doesn't look like it has a steep learning curve. not to me at least. the
discouraging thing is the "weird" syntax. i feel like rust is the result of
diverging ways of looking at things.

not saying it's a bad. just wish some effort were put into making a consistent
syntax.

seems weird to me that whoever decided on the function keyword "fn" would
write the "Option" type. they would have written "Opt". but no, it's "Option".

consistency is very underrated. and these things just look odd to me but the
rust community think it's okay, so, oh well...

~~~
kibwen
The general wisdom of language/library design is that abbreviations should be
used only for very common things, and only when those abbreviations are
unambiguous in context. Prehistoric Rust had a rule that all keywords could be
no longer than five characters (in defiance of Javascript's `function`), but
forums (including HN) endlessly complained about `ret`, hence today it's
`return`. :P (I admit that I wanted to Rust to change its `fn` to `func` once
Swift showed its hand, but such is life.)

Meanwhile, in 2020 `Option` might be on its way to becoming a widely-accepted
concept in language design, but back in 2011 it was still a radical idea that
Rust was trying to smuggle over the border from functional languages, against
the will of people used to languages with pervasive nullity. The language that
eventually supplants Rust someday might call it `Opt` (in the same way that
Rust turned C++'s `vector` into `Vec`), but back then `Option` needed all the
lubrication it could get without having to get bogged down in the abbreviation
bikeshedding.

~~~
zozbot234
The thing is that 'return' is not very common either, because Rust has
shorthand for returning at the end of a function :-P

I think the standard library ought to use slightly longer names since it's far
less strictly bounded than the set of language keywords, so I'm fine with
'Option'. 'Vec' is a bit awkward from that POV, but then again 'Vector' would
be a lot worse. 'Box' is also awkward in the same way but thinking about it,
it's not easy to convey the notion "this value is behind a pointer" so you
might as well use a conventional name and get it over with.

~~~
thomasahle
Why not call it Pointer or Point?

~~~
wwright
A Box is _not_ a pointer. It is an object with regular one-owner, no copies
semantics. Semantically, it just breaks the object out so that it isn’t
“internal” to whatever contains it (useful for keeping individual objects
small or working around the requirement that a type have a known, finite
size).

A pointer and a heap allocation are the obvious choice for implementing this,
but the semantics are notably different than just being a pointer. Rust also
does have pointer types which represent true pointers.

~~~
umanwizard
AFAICT, Box has exactly the same semantics as C++‘s unique_ptr.

~~~
temac
Where it _can_ have the same semantics, yes. But if you look at the details,
not exactly. For example Box is not nullable, but a not-nullable C++
equivalent is hard to do given the rest of the language.

~~~
umanwizard
Good point on the nullability; yes, that is indeed different from
std::unique_ptr.

------
wdroz
Unfortunately for me, they don't mention macros in this tour of rust. Even
after reading the official book, I'm still not comfortable with macro and
macro syntax. Do you have any recommendations?

~~~
kibwen
Note that I wouldn't expect a beginner to Rust to care about writing macros at
all. Macros are something that you might introduce to a project eventually in
order to abstract over some project-specific boilerplate (and only as a last
resort; there are usually better abstractions to reach for first).

I say this because someone coming from a functional language might be betrayed
by their instincts here: it is relatively rare for Rust users to write macros
themselves, and macro-heavy Rust code would generally be regarded as
peculiar/unidiomatic.

~~~
mprovost
It's true that writing macros is out of scope for an intro guide, but the
first "hello world" example uses the println! macro so you have to understand
how to use them right from the start. They're all over the standard library. I
struggled with explaining this when writing my own guide to Rust - do you dive
straight into explaining macro syntax in the first chapter, or just explain
how this one macro works and move on? Or don't explain it at all, which is the
(sensible) choice that this tour takes.

Unfortunately the language documentation isn't helpful either, looking at the
docs for println! [0] doesn't explain the arguments that it takes (other than
referring to format!, which is another macro [1]...) or what the return value
of the macro is.

[0] [https://doc.rust-lang.org/std/macro.println.html](https://doc.rust-
lang.org/std/macro.println.html) [1] [https://doc.rust-
lang.org/std/macro.format.html](https://doc.rust-
lang.org/std/macro.format.html)

~~~
pizza234
> the first "hello world" example uses the println! macro so you have to
> understand how to use them right from the start

You don't "have to" understand the `println!` implementation in order to use
it. It certainly helps like it does for any other API, but it can be treated
as a blackbox, and still be able to use it.

~~~
YesThatTom2
This is the essence of teaching: planning out what to gloss over and explain
later.

I see many tech:nerd people explain this bottom-up instead of bottom-down
because they can’t imagine skipping details for later. The reality is that
students are intrigued by “I’ll explain what that means later” and it builds
interest.

I explain how our website works by first telling a big lie: your computer
requests a webpage and we have one big computer that replied with the answer.
I then explain that I just lied. I then break it down: a web page requires
many elements. Each requested individually. I then explain we don’t have one
big computer but a cluster behind a load balancer. I then explain the many
benefits of a load balancer. Then I explain that the web cluster depends on
databases and other services.

All-in-all I expose 5-6 “lies” as I break down each component.

I’ve gotten positive feedback from both non-developers, entry-level
developers, and expert developers.

I’ve also seen people give a bottom up description and everyone was confused
at the end.

Why do top-down descriptions work better even though they initially gloss over
(lie) To the audience?

Because the high level description gives The audience a mental roadmap to
follow. Then we back up and walk through that roadmap in more detail. Then we
walk through again in even more detail.

The entire time the audience understands where we are going and fits each bit
of new information into their mental model, expanding it as we go.

Here’s how it feels to be explained to in a bottom-up manner: imagine I spent
an hour with you listing out left and right turns. At the end of the hour I
tell you “and that’s how You drive from NYC fo San Francisco”. JFC, Tom,
couldn’t you have started with that!?!?

Don’t be that guy.

An explanation isn’t a murder-mystery novel with a surprise ending. Start with
“these butler did it” and work backwards from there.

At Bell Labs we had a saying about presentations: “first show us your
conclusion slide. If we disagree, rewind to the first slide and show us your
talk. You have our interest. If we agree, stop. We can all go to lunch early.”

~~~
dagmx
I second this. I see too many people start with a bottom up explanation ,
which causes people to sour on the topic. It’s a mountain of information up
front.

Some topics, this can’t be helped with as much, but in most cases, starting
high level and progressively peeling back layers is a lot more effective.

That’s how most education is presented as well. It’s usually only domain
experts who DON’T teach that think every little detail is valuable up front.

------
jasonzemos
As a skeptic of Rust I really appreciate this. I was very pleased to find the
ASM option in the drop-down menu specifically. Coming from C/C++ I've found it
difficult to understand how and why Rust generates the code that it does. Rust
appears slightly less direct in its description of programs than C++ as it's
shed the hardware-driven abstraction of memory and physical layout. My comfort
level with seriously considering Rust for a next project is proportional to my
understanding of what it's doing under the hood.

Thanks! Looks great.

~~~
steveklabnik
The Compiler Explorer supports Rust as well, and is very good at this kind of
thing. You may want to check it out if you don't already use it for C++ stuff.

------
swordbeta
The playground is rather slow, is it possible to run this locally much like
how go's tour can?

~~~
marvinblum
From what I've heared, Go compiles much faster than Rust. But I'm only
experienced in Go...

[Edit] I mean you could just install Rust, copy the samples and run them
locally?

~~~
bouncycastle
Yes, I've noticed the Rust compiler does fancy stuff like check for similarly
named constants, check constants have uppercase names, do static analysis to
check that I've kept my immutable variables immutable, check that a semicolon
is always at the end, and so on. I've never found those necessary in Go...

~~~
ATsch
Last I heard, the biggest source of compile time in rustc is emitting
absolutely enormous amounts of LLVM IR and leaning on aggressive low-level
LLVM optimisation passes to clean things up. There are efforts to make most of
these optimisations earlier that have been landing in recent releases, but I'm
not sure what the overall state of it is.

~~~
swsieber
I they have started doing work on that? I can't recall what it was exactly,
but there was one constant or number (I'm so good at being specific) related
one that did the optimization on the rust side instead of on LLVM's side.

~~~
steveklabnik
[https://blog.rust-lang.org/inside-rust/2019/12/02/const-
prop...](https://blog.rust-lang.org/inside-rust/2019/12/02/const-prop-on-by-
default.html)

------
The_rationalist
I think this tour of Scala should interest rustaceans as many discover in rust
their interest for advanced type system/functional features. And Scala in this
aspect represent what rust should be in the next decade!
[http://dcapwell.github.io/scala-
tour/Partial%20Function.html](http://dcapwell.github.io/scala-
tour/Partial%20Function.html)

~~~
mrkeen
> When building apis that are given PartialFunctions, its your responsibility
> to make sure the given input is proper for the function.

That's not exactly the first 'feature' I'd want Rust to get.

------
cryptonector
> With so much difficulty in working with Unicode, Rust offers a way to
> retrieve a sequence of utf-8 bytes as a vector of characters of type char.

> A char is always 4 bytes long (allowing for efficient lookup of individual
> characters).

Please fix this! A 4-byte char is NOT a character but a _codepoint_.

------
pen2l
Sorry, off-topic, but something interesting I just went through: in the first
page, where it offers you multiple languages to choose from, one of the
options is "Interlingue". I've never seen it before, I didn't realize it was a
conlang. Anyway, I used my google-translate addon to select a couple
sentences, while having that lang selected... and it gave a comprehensible
translation... and recognized original lang as Spanish. I selected the next
sentence, it gave a comprehensible English translation, but recognized
original lang as Romanian! Another sentence: good output, but French! Another
sentence: again, perfectly good translation offered, but input lang recognized
as Corsican! Truly a bizarre experience.

------
vandal_at_your
Pushing this language and Go as required, responsible, NG languages is another
one of the foibles of the cloud/web and it's owners. For those of us in HPC
and scientific compute where is the practical reason to switch from C/Python
and the unix toolset?

~~~
DoctorOW
I'm in the web field generally. Those I've spoken to outside of that field
find Rust a much faster way to develop safe and stable programs that would
have otherwise been written in C. Feel free to take this with a grin of salt.
I suspect the C devs who don't like Rust haven't taken the time to discuss it
with me.

------
siraben
Is the naming inspired by Stroustrup's "A Tour of C++"? [0]

[0] [https://www.amazon.com/Tour-2nd-Depth-Bjarne-
Stroustrup/dp/0...](https://www.amazon.com/Tour-2nd-Depth-Bjarne-
Stroustrup/dp/0134997832)

~~~
Laremere
This looks very much like the Go tour:
[https://tour.golang.org/welcome/1](https://tour.golang.org/welcome/1)

~~~
jay_kyburz
Thanks for the link. It was great to read them side by side. I had my
suspicions, but I think I'm more of a Go person than a Rust person.

------
hn_reader_75
Off topic. Asking seriously, will there be any point learning some language
other than rust in coming days? Will rust be ubiquitous in future?

~~~
JJ4334
It's important to understand that hackernews, reddit or stackoverflow are very
small parts of the software universe. At my workplace less then 10% of the
devs are hanging around at hackernews or reddit. Some don't even visit
stackoverflow but just read the Java docs!

Rust is extremly popular here at hackernews and at reddit. It's a brilliant
language. I learned it and actually wanted to use it for some services at
work, but the team chose Go.

The impression of the spread of Rust one might get following hackenews or
reddit is far off. In the industry Rust is not even at 0.1%. Probably less.
The amount of Java, C and C++ projects is immense. That's at least what I can
tell from my almost 20 years of experience as dev.

Rust is 10 years old. It's not new. There must be reasons why it's not already
ubiquitous. And it's not the lack of language features or the lack of
promotion :-).

The reason is simple: The choice of the programming language itself is not
that important. How else can the world be full of extremly successful projects
written in PHP, Python, Ruby, Java, C#, C, C++, Go, JS, ...

I don't like to write code without algebraic types and pattern matching. I
don't want to check for null. But with Java or Go I have to and to be honest:
It doesn't matter. A good development process is essential for successful
projects. Language and tools ergonomics, matureness and stability come second.

That's why so many large projects are still on Java 8. They get the job done.
The same can be said from C++ and C. If C++ was so harmful, why did Mozilla
not port all of Firefox to Rust?

Rust could be a greater success in the industry. They just have to look at Go.
Go gets a lot right: Standard lib and stability. Generics don't really matter
if you want to build a successful product. I want it but I don't need it. A
large and stable standard lib does matter. The xml package in Go's standard
lib is embarrassing slow. But you can rely on it.

Rust needs a large company as patreon. It needs a more comprehensive standard
lib. It needs one async runtime in the standard lib and a http server and
client, crypto, etc.

~~~
estebank
> Rust is 10 years old.

Rust didn't have any pick up in adoption (understandably) until 1.0 in May
2015, as a consequence of breakneck speed changes before then as the
developers understandably wanted freedom to break things until then. Also, 1.0
wasn't a "feature complete" release, it was a "we promise not to break your
current code" release. It was an MVP. I would say it took a few releases
before it was useful enough without having to rely on nightly features. All
this to say is that saying that it is 10 years old, when code from 6 years ago
would be completely alien and not compilable today, is misleading by omission.

> It needs a more comprehensive standard lib.

Reasonable people can disagree. There's a difference between having a fat
stdlib that has the same cadence as the compiler, and having a "blessed" crate
ecosystem that can evolve on its own. Doing it that way can let people update
either their compiler or their dependencies independently of each other
(modulo minimum version bumps on libraries) and opens the door to more
aggressive deprecation schedules that the stdlib can never consider.

Your points about the actual popularity of the language are very true: Rust is
niche now and will likely continue to be so for a while, but I don't think it
will _remain_ niche.

~~~
jiggawatts
> deprecation schedules that the stdlib can never consider.

This is utter fantasy.

You can have a standard library that doesn't get deprecated often, or no
"standard" libraries at all.

Oh, I mean, sure, you can call it a "blessed crate ecosystem", but that's just
a label. A name. You can call it Bob's Best Bits, or the Stevens Standard Set,
or whatever you want, but _inevitably_ it'll be either:

a) Difficult to change because so many other libraries depend on it, _because_
it is the established standard.

b) Easy to change because it's _not_ the established standard and hence nobody
cares if it breaks the handful of things that depend on it.

Everyone wants option (c), where an established standard is magically easy to
change. But there's no such thing. Putting libraries outside the "std"
namespace doesn't help in any way.

~~~
estebank
In Rust you can have multiple versions of the same crate in your project. This
let's you update you your dependencies almost whenever you want _, even if
their transitive dependencies require different versions of the same crate.
You can 't have multiple versions of the stdlib (the way that things are set
up today).

_ Some crates re-export typed from their dependencies, and to use those you
have to match in the right crate version. This is an anti-pattern, but it
happens.

------
rimutaka
I think much of the official "rust-by-example" would benefit from using the
rust playground instead of the printed examples.

~~~
the_mitsuhiko
All code blocks in rust by examples can be edited and have a play button.

~~~
rizky05
And most of that cannot be run on playground because of incomplete source
code, missing dependency or wrong configuration.

~~~
steveklabnik
That has to do with the contents, not the playground.

Also, many examples have hidden context that if you open the example in the
playground, you’ll see and will make compile.

------
mendyberger
This site can actually be used on mobile, cool!

------
vanderZwan
> _Execution operation failed: Compiler execution took longer than 12000 ms_

Are my privacy add-ons too strict or is the server overloaded at the moment?

~~~
pcstl
Probably getting the good old HN hug right now. Might want to try later.

------
philipov
Did anyone else notice Interlingue in the language options? Maybe we could get
a Tour of Rust written in Esperanto :)

~~~
richardanaya
Tour of Rust english author here, David
[https://github.com/Dhghomon/](https://github.com/Dhghomon/) our Interlingue
writer was one of our most passionate translators. We'd be happy to have
Esperanto.

------
bytematic
Why does the compile debug information get printed to the standard error area?

------
CubicsRube
Tour de Rust? No? OK, I'll show myself out...

------
fctorial
Too bad mr crabs isn't the guide.

~~~
armSixtyFour
He asked for too much money

