Rust Programming Techniques

Nicholas Cameron
lca2018.linux.org.au/schedule/presentation/22/
Rust is a language for fearless systems programming. It offers memory safety, data race freedom, and a modern programming environment, without sacrificing low-level control over performance and memory usage.
Learning a new programming language is hard. Even after mastering the syntax and type system, learning the libraries and techniques can take years. If you've read or written Rust and want to improve, this talk will give you a turbo boost! This will be a very practical tutorial, aimed at taking your Rust programming to the next level. We'll teach some core Rust design principles by covering a few key topics in depth. This tutorial is aimed at those with some Rust experience, but if you're a total beginner, you'll still learn a lot about what Rust programming is like in practice.
The tutorial will start with programming 'in the small': we'll explore some key library types (Option, Result, and Iterator) and cover practical error handling. Putting these together we'll see how to structure your control flow to write clear, succinct programs. We'll then cover some larger-scale design issues - using ownership as a primary architectural principle, and abstraction using traits.
You'll learn how to be more productive in Rust by writing clean and idiomatic code. You'll learn to work with the language rather than fighting against it.
This talk was given at Linux.conf.au 2018 (LCA2018) which was held on 22-26 January 2018 in Sydney Australia.
linux.conf.au is a conference about the Linux operating system, and all aspects of the thriving ecosystem of Free and Open Source Software that has grown up around it. Run since 1999, in a different Australian or New Zealand city each year, by a team of local volunteers, LCA invites more than 500 people to learn from the people who shape the future of Open Source. For more information on the conference see linux.conf.au/
#linux.conf.au #linux #foss #opensource

[@nathanielwoodbury2692]

This video was the thing that actually got me to finally understand Rust. I cant say how much this has helped me. I watched every second of it.

[@dishonour1461]

V Xbox, x has, g, and g, x Yaz g

[@dishonour1461]

The only

[@dishonour1461]

The only time - 90

[@dishonour1461]

I caught a

[@dishonour1461]

Fyz9f

[@daveduvergier3412]

I think this talk needed to go in earlier discussing move semantics, as otherwise the difference between iterating over Vec vs &Vec is very confusing - the key observation being that IntoIterator *converts* a Vec into an iterator over the T values, such that the original vector is moved out of and no longer available. Most Rust tutorials and books I have seen hand-wave over this stuff in the interests of presenting iteration as super ergonomic, which it is, but I was very confused by this until I worked out what was actually going on

[@mybigbeak]

Really enjoyed this viideo. Been looking for a while to find something that went a bit deeper into some details of rust. Thanks

[@mohammedtalha4649]

Great Job. Would love to have more in-depth videos such as these focused on application. Would help us adapt rust easily and better correlate to the features of classic programming languages such as C/C++

[@ziliangchen7111]

Great talk. May i ask where i can get the slides as ownership is not covered, like to take a look at that piece ?

[@mikeg9b]

I'm only 14 minutes into this talk, but I'm already picking up on influences from Haskell.

[@Rene-tu3fc]

@Niranjan Raju scala is jhaskell, rust is chaskell

[@jeffparent2159]

I love that until I start thinking Haskelly and run into things not in Rust. Why won't they just add GATs and Higher Kinded Polymorphism /rant-over

[@TheMrKeksLp]

@@jeffparent2159 They are coming... eventually. They're super hard to get right that's why they take such a long time

[@tervaaku]

I wonder how much of that is from ML, because rust is pretty heavily influenced by ML, the compiler was even original in OcaML

[@RyanLynch1]

great talk from a very knowledgeable speaker! glad he's able to explain to outsiders the great benefits and all

[@martinschrodt5797]

Very informative, thanks a lot!

[@tanuvishu]

Awesome talk

[@Liaret]

One thing I would have mentioned when covering `.and_then()` at 36:00 is that `and_then()` is just mbind (monadic bind), i.e. the `>>=` operator from Haskell. This becomes pretty obvious when you closely examine its signature, but it was less obvious for me when I first saw it, because of "strange" (but sensible) naming. So you can chain functions-which-may-fail with .and_then()s, the same way you can chain promises in js/ts, or the way `do` construct sugars monad bindings in Haskell.

[@nicolasmagee1780]

I'm seeing this for the second time. It's a very good review!

[@krzesimirbonobo6682]

Good talk, Nicholas could work on his slides a little bit more though (syntax coloring, side by side code comparison, more meaningful function names etc. and add short 5min intro about language basics)

[@rishabhsharma5050]

any follow up video that we can refer to after completing this one?

[@Dygear]

The speaker is phenomenal, and really groks the subject.

[@RyanLynch1]

makes a lot of sense considering he's working on the team that makes it 😂

[@creestooz]

I think code listing in 46:50 needs a derefernce inside closure `.filter(|x| *x > 1)` or a readable ref '.filter(|&x| x > 1)'

[@emoutraspalavras-marloncou4459]

For me '.filter(|X| X > &1)' worked (borrowing the number value)

[@jonnytang6578]

nice talk

[@kvadratbitter]

Open question regarding iter() at 37:30 I’ve just started with Rust and find myself often using iter() to go from result just to get the nice functional methods found on Iter that’s not in Result/Option. It will obviously only iterate 0-1 object so it feels a bit bad/strange to “iterate” it. Is it idiomatic/normal/ok to do this? An alternative would be to make the same code more procedural which I don’t like quite as much. Since this is a KZbin comment section I’m sure people has opinions? :)

[@TheMrKeksLp]

Good question! In my experience using Option::iter() or Result::iter() is indeed not the idiotmatic way. And I'm surprised to hear you say that Option and Result don't have similar functional operators because they do! :) Option has map, map_or, map_or_else, and, and_then, zip, copied, flatten and many more. In fact, at 30:09 he uses Option::map which is the idiomatic way to model such a thing Option: doc.rust-lang.org/std/option/enum.Option.html Result: doc.rust-lang.org/std/result/enum.Result.html

[@CrapE_DM]

I understand why the guy is confused about Result's T and E being in the order that they're in, since most other languages do it in the reverse (likely because of Haskell starting it). My question is why the heck they were in the other order to begin with. I THINK it's because it's inspired by or actually derived from the Either type, where "right" sounds more like it should be the primary type than "left", and so it was made the primary side. But you could have named it "first" and "second" or "primary" and "secondary" or something like that and made it so that the first type listed is the primary type. This has bugged me since the first time I saw it, and I was so proud of Rust for doing the obvious thing.

[@richard1598]

Does this "wrapping-into-option" hit the performance (i.e., when using iterators which seem to wrap every value into an option just to indicate some end of list)? Or do they somehow get compiled away?

[@TheMrKeksLp]

They're generally as "zero cost" as possible. Let me put it this way: If your function needs to be able to return either something or nothing at all, you obviously need to encode that information somehow. In that case there's no faster option than using Option But often they are also just optimized away quite well: e.g. Option has the same representation as a simple pointer to T. Also because predicates and such get "compiled into" the functions they're passed to they are pretty much guarenteed to be inlined. So `iter().map(|x| if x > 1 {Some(x)} else {None}).filter(|x| x.is_some())` will (with optimizations on) never construct an Option object

[@cat-.-]

Knowing how awesome rust really is I feel this person woefully undersells it lol

[@yanushkowalsky1402]

coool thanks Man

[@ogal]

Nice content

[@cccPaKYccc]

lol, why did they vote traits over ownership? difference between functions.methods.traits and functions.methods.methods is easy and could be left as an exercise to the reader. :D I can't find the part after the coffee break. Anyways, good talk.

[@joech1065]

Exactly. So frustrating.

[@gloubiboulgazeblob]

Indeed...Understanding Ownership is so basic, so crucial, that it comes BEFORE any fancy thing in Rust !

[@nceevij]

Does anyone knows where to get the slide of this session ?

[@rodelias9378]

This was really noice!! Thanks! Btw, is the speaker that guy from the Split movie? 😅

[@anteconfig5391]

30 min in and I'm thinking maybe I should learn the language first, before allowing myself to get even more confused.

[@EivindDahl]

This is, kind of like, a good talk

[@systematicloop3215]

I think it's, kinda like, trying to be like, a good talk, but it kinda like, fails, on like, the communication side of like, things.

[@31redorange08]

14:57 With “positive”, did you mean non-negative?

[@aykxt]

what's the difference?

[@31redorange08]

@@aykxt 0 is non-negative but not positive.

[@nodehead9475]

why are people sitting awkwardly around him LUL

[@cthutu]

Great talk, badly designed slides although their actual content was good. Some of those slides could be combined (especially comparing C++ vs Rust) so that the talker didn't have to switch between them all the time.

[@alexisfrjp]

7:30 why would it be mutated? are we talking about a multi-threading app? why is there no mutex/semaphore then?

[@Igigog]

The thing is not about what should be done, but about what could be done. You should introduce mutexes, but you could go without them out of inexperience or basically any human error. You cannot do it without mutexes in safe Rust.

[@alexisfrjp]

@@Igigog agree, thanks

[@jonasbirkeli]

9:26 troop ready

[@PaulSebastianM]

24:44 not err => return err but Err(err) => return err

[@Lucas-md8gg]

You don't need the return keyword I think

[@TheKoffrig]

Monads, monads everywhere

[@thingsiplay]

I hate people playing on their phone in a talk. This is very disrespectful.

[@jklappenbach]

Ergonomic? Rust is anything but that. However, the contribution of borrow checking is really significant. Lifetimes? Absolute kludge. This actually motivated me to brush off ANTLR and explore how else this could be handled, as well as polymorphism. The choice between hacks or unending boilerplate is not an attractive one.

[@aymanal-qadhi8225]

Unfortunately, your C++ examples are very misleading. For example, the code you showed at 42:03, could be written in a safer and more elegant form using C++ as the following: void ping_all(const std::vector& foos) { for (const auto& foo : foos) { foo.ping(); } }

[@CrustyAbsconder]

This is just my personal opinion, but I hope it helps you with your presentations. When you are speaking you just way way too many unnecessary words. You speak using the word "like" in places where it is not necessary. You pause and say "uhh," or "uhm" and so, etc. You say "actually" too much. You put in words to exaggerate something, when it is not necessary. That all being said, I can only imagine it is difficult to explain the concepts of rust-code to people that have no idea how rust-code works.

[@MMABeijing]

i think.u r missing the entire talk

[@alexisfrjp]

The talk could have been even more amazing with much better preparation. Speaking in front of audience is a skill and something he should train for, the "uhh" "umm" and all these sounds are quite annoying. I still haven't found any good resource explaining the rust's spirit. They all show examples and explain a bit without saying the Why. (yeah mutable variables are bad but all languages have that and it's still working, tell me why it's better instead... and why I just can't use const in C/C++/javascript/... that has the same result) They should also stop comparing it with other languages. That's so wrong. It's like learning a new speaking language, at one point you just need to stop translating to your native language to actually learn otherwise you just learn your native language with different words. And that also makes the assumption the listener knows those, that isn't always true.

[@alainterieur5004]

why are you constantly creating new programming languages my brain is too lazy

[@NoNameAtAll2]

Fortran68 is all you ever need

[@alainterieur5004]

@@NoNameAtAll2 I would say C is all you ever need instead

[@nilstrieb]

@@alainterieur5004 C is for people too dumb for assembly, which is for people too dumb for machine code.

[@alainterieur5004]

@@nilstrieb yes and then you have to rewrite your code for every cpu architectures possible big brain

[@nilstrieb]

@@alainterieur5004 as I said, most people are too dumb for that

[@hineko_]

I wish the official rust book was this clear. Instead it feels like it was written by a woman(or a feminine guy) trying to explain you stuff through real world analogies as if you were a child.

[@baka_geddy]

wtf?