
Learning Rust - dumindunuwan
https://learning-rust.github.io
======
mswift42
Exercises, I want Exercises, no I need Exercises.

In order for me to learn anything, I need some form of "homework". If you want
to teach me a new language, a new framework, I need to "get my hands dirty".

Working through exercises makes sure I actually understand what I am reading,
and sometimes it even shows me I don't understand what I thought I did.

~~~
jordigh
How about Advent of Code? They start out easy, but after a while the
difficulty is all over the place, and it'll force you to seek out new features
of the language. It's a somewhat "realistic" way to learn the language,
instead of having a set of more contrived set of exercises that only make you
look at a particular part of the language.

The first day, for example, will kind of force you to figure out how to parse
arguments, how to loop, how to convert strings into ASCII... all basic,
practical tools that you will need sooner or later anyway. Now it's your job
to pick up a Rust reference, look around for the tools that you need, and use
them to solve an actual problem.

That's how I got very comfortable with D.

[http://jordi.inversethought.com/blog/advent-
of-d/](http://jordi.inversethought.com/blog/advent-of-d/)

If you do this for Rust, I'd love to see a blog post like the above.

~~~
asimpson
100% agree with this! I used Advent of Code this year to explore Common Lisp.
If you have any programming experience it becomes a fun hunt of "ok, I need to
loop over an array. How do I do that in X lang?".

------
_Chief
From the github readme

> I am a Sri Lankan Web Developer who lives in Vietnam. So I am not a native
> English speaker and just learning Rust

This guide is so well done, props to you. I haven't worked with Rust yet but
your docs make it seem so easy to work with.

~~~
dumindunuwan
Thanks, glad it helped :)

------
hokkos
I love those succinct introductions to languages, I find it easier to
understand when you don't have to read lots of text and languages
possibilities are written as a series of quick examples.

What I miss from Rust learning material is a series of exercises that focus on
reference, lifetime, ownership where you have to fix some code to make it
compile.

~~~
shepmaster
You may be interested in Rustlings:

> Small exercises to get you used to reading and writing Rust code. Includes
> practice reading and responding to compiler messages!

[https://github.com/carols10cents/rustlings](https://github.com/carols10cents/rustlings)

------
vvanders
Looks really nicely written and laid out.

One note on borrowing/ownership that really made it click for me was that to
move from &mut T to &T you have to transition through owning the value type,
so:

&mut T -> T <\- &T

Whichever scope holds the actual value-type is the only scope that can make
that transition(absent cases like RefMut)

~~~
danieldk
Could you clarify you mean here? Something like this is perfectly valid:

    
    
      fn no_mut(a: &mut usize) {
        *a = 10;
        let b: &usize = a;
        println!("a: {}, b: {}", a, b);
      }
    
      fn main() {
        let mut foo = 42usize;
        no_mut(&mut foo);
      }
    

If such pointer weakening was not possible, how would you be able to call a
method that takes _& self_ on binding of type _& mut self_? Of course, you
can't use _a_ mutably while _b_ is in scope. So, something like the following
results in a compiler error:

    
    
      fn no_mut(a: &mut usize) {
        let b: &usize = a;
        *a = 10;
        println!("a: {}, b: {}", a, b);
      }

~~~
vvanders
Actually you're right, I didn't realize that the compiler treated a single
&mut references like that.

I wonder if what I'm thinking of involved &mut self captures that were
happening as part of an impl on a struct. There's definitely some cases there
where I was getting tripped up on it.

~~~
vvanders
Ah, now I remember why I tend to use this model:

    
    
      use std::thread;
    
      fn no_mut(a: &mut usize) {
        *a = 10;
        {
            let b: &usize = a;
            println!("a: {}, b: {}", a, b);
        }
    
        let b: &usize = a;
        thread::spawn(|| {
            println!("b: {}", b);
        });
      }
    
      fn main() {
        let mut foo = 42usize;
        no_mut(&mut foo);
      }
    

Similar code but the move throws an error(as it should).

If you don't have the value type then you're constrained by the parent mut
lifetime here so it's not just as simple as a conversion that you can then
pass around. Otherwise you need to consider all the lifetime scopes which can
get a bit unwieldy.

~~~
danieldk
_If you don 't have the value type then you're constrained by the parent mut
lifetime here so it's not just as simple as a conversion that you can then
pass around._

You cannot move any closure to _spawn_ that captures a non-static reference,
since there is no guarantee that the value will live during the lifetime of
the thread. (The closure is required to be _Send + 'static_.) E.g., you can't
do (moving to a non-Copy type :)):

    
    
      let foo = String::new();
    
      let t = thread::spawn(|| {
        println!("foo: {}", &foo);
      });
    

You could move the captures, including _foo_ , but then _foo_ cannot be used
in its original scope anymore:

    
    
      let foo = String::new();
    
      let t = thread::spawn(move || {
        println!("foo: {}", &foo);
      });
        
      // This will give an error, because foo is moved.
      println!("{}", foo);
    

Note that only moving values works, this does not compile (for the same
reasons as the first example):

    
    
      let foo = String::new();
      let bar = &foo;
    
      let t = thread::spawn(move || {
        println!("bar: {}", &bar);
      });

------
Scarbutt
For devs, equally familiar in rust and python and ignoring libraries, would
you say development speed in both languages is almost the same?

~~~
siscia
I really don't think that I could code any faster of what I code in rust.
Especially if you consider the overall quality of the work.

In my humble opinion python give the impression to move fast, but when you
need to maintain the code base the rust compiler is simply too wonderful.

~~~
chc
I suspect people probably can do it a bit faster in Python, but like you say,
you wouldn't necessarily end up with the same quality of work. The Rust code
is likely to be quite fast and very solid, whereas the Python code is likely
to be "eh, fast enough" and "stable as long as nobody says the word 'thread'
within a 10-block radius."

------
piracykills
I really want to learn and use Rust, but just lack the motivation, especially
when APIs turn out to be incomplete - I think the last one I saw was multicast
not allowing me to set the send interface.

I guess the main draw for me to any given language is great libraries with
great APIs. Python has those, Javascript has those, C++ has those, Rust... not
so much yet.

~~~
childintime
> I guess the main draw for me to any given language is great libraries with
> great APIs. Python has those, Javascript has those, C++ has those, Rust...
> not so much yet.

Well... what makes (especially) Rust libraries great is the relative absence
of bugs. I can use a Rust library and have great confidence some ugly bug
won't bite me later on. The developers of the libraries you (don't) mention
continuously struggle to achieve the same property.

So in a sense those libs are not at all great in the same sense that a Rust
library is!

------
earenndil
This looks like a fairly nice website. For someone coming from a background of
C and D, but familiar with quite a few others, I have to ask: what makes rust
different and better? Aside from memory safety, what reason do I have to
choose rust over another language?

~~~
Drdrdrq
Resource safety and expressiveness on level of Python (or close) combined with
speed of C.

That said, while I love the idea of Rust I find the language itself offputting
somehow. I don't know, maybe I just need to give it another try.

~~~
sushisource
For me it's a love hate thing. I love the way it stops me from doing dumb
shit, and really makes you think hard about how to architect properly.

I hate annoying little nitpicky stuff like it won't auto-upcast a u8 to an
i32, for example. There should at least be a compiler flag to allow that.

I mostly love it though. The stuff that bothers me is relatively minor and I
think will go away as I get more fluent with the language.

------
talloaktrees
How does this compare to the Rust Programming book?

~~~
rayascott
Programming Rust has 21 chapters and is 583 pages long. I’ve read it, and I’ve
also read the online Rust Book (both several times). Most chapters are in the
order of 20 to 30 pages long. Programming Rust is one of the best programming
books I’ve ever read, and I’ve been coding professionally since 1997. If you
want to get an A+ in Rust read Programming Rust a few times. You can see the
entire Contents section of the book on Amazon. Below is a list of chapter
titles from Programming Rust that get little to zero coverage in this Learning
Rust website.

Ownership. References. Expressions. Error Handling. Enums & Patterns. Operator
Overloading. Closures. Iterators. Collections. Strings & Text. Input & Output.
Concurrency. Macros. Unsafe Code/FFI - the coolest part, they show you how to
create a safe wrapper around libgit2.

~~~
AlexeyBrin
There are two books with similar titles and I'm under the impression that you
don't talk about the one the OP had in mind:

[https://www.amazon.com/Rust-Programming-Language-Steve-
Klabn...](https://www.amazon.com/Rust-Programming-Language-Steve-
Klabnik/dp/1593278284/)

[https://www.amazon.com/Programming-Rust-Fast-Systems-
Develop...](https://www.amazon.com/Programming-Rust-Fast-Systems-
Development/dp/1491927283/)

I think both are good books, I already have the second one and preordered the
first.

~~~
rayascott
I assumed he’d misnamed the book, switched the words around, as your first
link points out (“The Rust Programming Language”), there isn’t actually a book
called “Rust Programming”, and “Programming Rust” seemed like the closest
approximation.

------
faitswulff
This is very readable. Thanks!

------
anon335dtzbvc
Duplicate?

[https://news.ycombinator.com/item?id=16048065](https://news.ycombinator.com/item?id=16048065)

~~~
dumindunuwan
At that time search was not working, had bit ugly ui, no indicator for current
page and etc. Even it's duplicate, this time people actually saw it correctly.
So sometimes trying things again is a good thing :) Have a nice weekend!

------
yusrilhs
I trying use rust, but I don't know why sometimes cargo is like hanging to
retrieve from github.

~~~
steveklabnik
Please file bugs! We'd like to track it down.

~~~
ishanjain28
It's probably a git/libgit issue. I reported a similar issue(Cloning/Pulling
commits from github took forever, Transfer speeds going as low as 1 kbps when
my connection was 50mbps).

They asked me to run some commands and log output to measure packet loss/speed
etc. and then told me that my connection had 2-5% packet loss which was
causing all the problem and I need to talk to my ISP or get a better
connection.

I switched my ISP after that and its not a problem anymore.

------
Animats
I used to know Rust, but I got tired of the churn and went back to Go.

~~~
steveklabnik
What churn, specifically?

Anything you learned since May 2015 should still be very relevant. That's
almost three years ago.

