Rust Programming Language FOSDEM Rust Devroom 2018, 6 Feb 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Matthias Endler - Idiomatic Rust

Description

Writing concise and elegant Rust code

Rust is a big language and it gets bigger every day. Many beginners ask: "What is idiomatic Rust?". This talk will highlight simple tips to make your Rust code more elegant and concise, and introduce you to my peer-reviewed collection of articles/talks/repos for writing idiomatic Rust code.

Coming from dynamic languages like Python, JavaScript or Ruby, many Rust beginners are missing some guidelines on how to write elegant and concise Rust code. For this purpose, I started a project called "Idiomatic Rust", which is a peer-reviewed collection of articles/talks/repos which teach the essence of good Rust.

In this talk I will introduce the project and show you some quick tips on how to make your Rust code more idiomatic. I will cover error handling (e.g. Option to Result conversions, the failure crate), efficiently working with (built-in) traits, and some more.

Matthias is a Backend Engineer located in Düsseldorf, Germany. His interests are scalability, performance and distributed systems. At work he improves the infrastructure at trivago by making it faster and more reliable. When not on his laptop he plays guitar and drinks hot chocolate.

Rust devroom @ FOSDEM 2018
https://fosdem.org/2018/schedule/event/rust_idiomatic/

These talks have been recorded at FOSDEM (https://fosdem.org/)
This work is licensed under the Creative Commons Attribution 2.0 Belgium Licence.
To view a copy of this licence, visit http://creativecommons.org/licenses/by/2.0/be/deed.en

A

Welcome everybody and I'm very happy that you made it here, especially that it's 9:30 in the morning on a Sunday and maybe I, feel few have been drinking yesterday. So I appreciate it. Also the people that are on the livestream kudos to you I hope I, don't disappoint.

A

What I want to talk to you about is idea, Matic rust and it's a huge topic. I want to show you a little bit on what I learned in my journey using rust in the last a couple years and how my code evolved over time, but first Who am I. I'm mateus I live in Dusseldorf I'm, a backing engineer at Chicago. I do a lot with website performance monitoring, metrics talk to me about it. I'll do like programming languages, a lot so I'm kind of a language, nerd and I. Also like hot chocolate.

A

You can find me on various places on the internet, so on Twitter and I also have a website. And now you know my your expectations are somewhere here for this talk, but Russ is a big language and it's getting bigger every day. So I cannot possibly cover everything in 20 minutes. That's insane! So lower your expectations a little bit.

A

This is going to be something more practical, something more hands-on.

A

You might be saying: okay right, why should I even care? Why should I watch this talk? Well, when I started programming, I was I was attracted by languages that were simple, beautiful, elegant that had a concise, syntax and I had a favorite language, of course, and by now you might have guessed which language that is, of course it's Python and I did a lot of Python in the past and I appreciated what they call the sin of Python, which is those rules here. Are the rules I hope you all read them all?

A

They are very important. There will be a test after the talk now those rules they are more or less the the the gist of what it means to write: good well-formed, Python code, pythonic code. It's even a word we're not going to talk about Python anymore, but we want to talk a little bit about rust. What is automatic rust and for that you need to know what is automatic, I hope you've seen the previous part from antonin, which is super awesome.

A

You should check it out, if not so, I will focus on the idea Matic part here, and there is a definition which I quite like, which is the most concise, convenient and common way of accomplishing a task in a programming language. That's from the main three, that's from not from me all of those things underlined are links, so you can check them out later. So that's quite awesome. This description, because yeah it's concise, convenient and common, so that makes it automatic and not in any programming language, but in a programming language, you're. Writing.

A

It should feel natural in the language. You're writing. So, if you're a Java developer, this might be idea. Matic, Java, I'm, just kidding, of course I'm just kidding. This is non idea, magic code. You can see here that this code will work. It's checking for a boolean value, but in a kind of awkward way. If you, like those kind of things, there's also leak down to the down at the bottom.

A

For more of those, mmm but everybody can agree that this is not really idea metric code right, most people will say yeah that doesn't feel right. But what is really good code? What is solid, ergonomic natural code?

A

You can focus on many things, but if most people would say yeah you could focus around those areas, syntax semantics and design patterns, and since this is a small talk, I'm not going to talk about syntax or design patterns, I'm talking about semantics for syntax, just use a standard, any standard can be rust form it actually use rust form it. It's quite nice for design patterns. There is a project from one of the core members, Nick or Cameron rust.

A

Unofficial patterns do checked it out, but for semantics, I did not know where to start and I was looking for a lot of resources and I couldn't find him when I started. There was literally none so I had an idea.

A

What what if I started, collecting a list of things where intermediate rusty developers could go and read about more sophisticated code. So there are a few links from projects and talks. Actually, a lot of people that contributed are here so yeah ask them if they know something about it. Please contribute to that. I guess this will be a first step towards something that is a guideline, not a sin of Python, because we are not Python. We don't want to be Python.

A

We want to be something like rust, but a start of a conversation on how to write idea, Metagross code. So if you find something on the web- and you say this is missing on the list- shoot me poor request- I'm gonna transferred it eventually to some official space, so you are not locked in or something I would happily accept your recommendations for that.

A

That is all very nice and stuff, but it's also very theoretical. So why not look at a very practical example and for that I thought we build a little tool. A little library and the case study is going to be handling money in rust. So we think about the data object. How does a data object look like and how does the Pilar help us guiding us along towards something that is more convenient to use and feels very natural? So the task is parse money. What can go wrong?

A

Let's parse some money, so twenty dollars, forty two cents or 140 euros. This is our task for the next couple minutes and as a beginning, rust programmer. You might start with a function like this. You take an input which is a spur which is a borrowed string which lives on a stack and you do something with it and this something might go a little bit like this. First, you need to decide what you want to return, so you could say yeah I, don't know in my previous language, I use a tuple.

A

For that I say my monetary value is an I-32, so an integer and the currency is a string, so I take the input, I split it on the whitespace and I collected into a vector. So this part thing in the end has two components: if everything was right, one is the monetary value or the amount and the other one is the currency and we check if we have an amount.

A

We just parse the first element in our vector and if we have an error where we return some magic number as we do in C or any many other languages, and we say we have this invalid currency and if not, then everything was all right and we just take the second element from our vector which contains the currency. We parse it into a string and we return it as a tuple.

A

Yeah can work, not so beautiful. Why? Well, let's look at a little bit about what I'm doing you I? Have this explicit error check so I'm checking I have a condition so I'm branching I need to have more metal overhead to remember that there can be something wrong and also I. Have this number -1, which you need to remember, is not a correct value and -1 is a totally correct value for a currency for for a monetary value and invalid yeah somebody invents a currency called invalid.

A

Well, bad luck for us, but nevertheless most people in a community might agree that this is not the way you write, solid, Ross code. So the first thing you can do in a prototype is to replace this error. Checking with unrep a lot of people will say: unrep is evil. I, don't think so. Unrep is very can be very idea.

A

Matic, especially if you're writing a prototype, and if you want to do get something done real quick, then unwrap can help you because later on, actually what is unwrap unwrap will just try and fail, and there will be a panic if there was a failure, so you might say wow. This is dangerous and it is, but also it helps you get going. You don't need to think about the error handling part in the beginning. So that's not bad. It's just a pattern that a lot of people use and you will see why.

A

So if we take this library actually this function parses our thing- we can use it to parse our money and we're done right. Well, what if somebody tries to parse some sub euro amount? Well, bad luck! You get a compile error, actually a runtime error with a panic. Even though a rust is safe, it cannot save you from not declaring what you want. So our intent, our intent. We must define.

A

Actually this is my colleagues cat I think it's very ugly, but that's just a side note and it should be a meme somewhere. So we get an error, saying called result unwrap on error, and then we have this weird parse in error, invalidated and so on. What happened well turns out.

A

We panic on this unrep here, I told you well, it's it's totally fine to use that and the reason why is that you can later when you have something running search for unrep in your code and just replace it with something nicer and have error handling out of the box, so you have the best of both worlds: rapid, prototyping and safety when you need it. So one common pattern to use is you replace that unwrap with something we call the question mark operator or the carrier operator? That's in line number three behind the parse.

A

We just replaced unwrap with question one. Let me go back one second, you see unwrapped becomes a question mark and then we return a result. So in the end and line number five, you see. Okay, that is the correct result. So when everything went right, the happy path and if there's an error or so then, for example, in line number three- the question mark means there can be an error. So in this case we just returned in parts into error. You can see in line number one.

A

At the end, there is the parts in error now, so we just pass on the arrow to the caller and we don't deal with error handling anymore. It's it's also a better concept and exceptions for us, because these are zero cost. You don't have a runtime overhead with that, but you have it's very concise and the way you want to write your code and in the way of error conditions that can happen. So all of that is covered now, if I covered I mean if you take the same example from before.

A

At least we don't panic anymore so, but we get something which is looking a bit foreign or a bit alien. You get an error, parsing error of kind, invalid digit, so parse int error is in fact an enum and enum has actually percent error.

A

Has a kind field and kind can be many different types of error kind and for a rusty fella, but that totally makes sense, but maybe not for a on Russ developer or somebody using your library em, but first we're trying to parse a float here right and we get a parse int error, so we use the wrong type for the parsing. If we want to pause a float, maybe use a float, there might be people here in the audience which have a little experience on how to handle money. Float is not a good idea.

A

Don't use float in production code. This is not about proper business logic. This is about Russ. So that's why, in this talk it's fine but for production use. Please check out the link at the bottom, which you totally cannot read any more like I see faces stretching up, but there is a link at the bottom saying caution. Please don't use float for real-world money object in this case. I want to improve the error handling here so think about the rust part, but if you're a business person, it's totally fine.

A

If you don't accept that solution and let's go back again, we have Ted float 32 and we return the parsefloat error now. So with that, when we parse that thing yeah, we actually get the first real result, which is our tuple of float and then a currency. What about this one?

A

Okay! We are missing a currency, that's an error variant because we can hardly know what currency that is, we don't and what happens if we run the code well, we burnt, because we died at runtime again because it says Lane is one but index is one and why.

A

Actually, look, let me show the cat again just for good measure. Yeah I forgot that I had it in the slides this we parse the first element. We try to get the first element from our vector, which is undefined.

A

We should handle that we can handle it explicitly and say. If the length of our vector is not 2, then we don't have an amount and the currency. So then we need to return an error. You can see that I don't write return anymore, because return is implicit. Everything in Russ is an expression and the last statement will be returned or actually the the result of the expression will be returned to the caller. In this case, in line number 4 debts are returned and in line number 7, that's also return.

A

So you can see that we do this explicit check for two elements and also you can see that we have a new type here, a custom error which we call the money error, and in this case the variant of that is a parse error.

A

You define it like this. You have money error which is can be any type in interests. No, like an enum, an enum with one word variant, which is parse error. You need to implement error for this type. What you get from, that is, when you try to print it. This is what will be printed.

A

So that's just a trait that we implement error is a trait and description is a method that we need to implement, which belongs to the trade, and it's also the only method in the trade and when we implement this yeah more or less, we have an arrow type at the top. You can see debug. Do you write debug? There is some kind of standard way to have something: some output, when you try to print it, because there is no real yeah yeah, it's actually.

A

Actually, you can provide a default output for that, and this is a hand with the derive and for our description. This is handled when we try to print something that the user should understand. Also, we need to implement a display trade and that's a lot of boilerplate. You might say you have this display trade. You have the arrow trade.

A

You even have another thing for converting from our parsefloat arrow to our internal money error, so we wrap around the internal standard library, parsefloat error and we get something that is our money error.

A

This is a lot of code, especially for a beginner, so there's a library to make that easier, which is called failure and the same code that you see here can also be expressed like this, even there's even more in that slide. Actually, we have two error types here. We have parts amount error and we have parts. Formatting error pause amount for yeah parsing, the amount of course and parts formatting. If we don't have two elements, so we can separate the arrow types here and yeah.

A

We keep the implementation for parsefloat arrow down there to do the implicit conversion automatically with that you get beautiful error messages, so you say: if you're trying to parse something without a currency, you get expecting amount and currency. If you price, something which is not a digits in the beginning, you get a possible error kind invalid, all of our own types and the usual suspects for the normal case. But still we check for the length here explicitly and yeah it's kind of yeah.

A

Then there might be a better way and there is using sliced patterns with sliced patterns. You can say, I take this slice in line number 4, I take the vector and I take all of it. So that's what we have two dots here. We take the whole thing and we compare it to different outcomes. So match means compare it to different versions to different outcomes of the computation and we compare if we get an amount in the currency.

A

If so, we return it and if not then yeah, we throw an error, but this is just in nightly right now, but this will help you later to make your code even more readable.

A

So now we use our own money type also, instead of returning a tuple and there's also the way to implement it is you you use a struct money, you have two fields, amount and currency and this implement block down there. This is where you write your methods and yeah. We just have a new function, which returns a new object of money and for the currency.

A

We also use a currency enum and we have dollar and euro as types and we can also implement from string, which is another trait for the currency, and we only need to implement one method which is called from string and in there we do the matching of the string input so dollar or euro and anti output of this function. So when we call Paris on a string which is euro or dollar, then this will return a an object of type currency of this enum and the same can be done for our money type.

A

We also implement from string on that money type. You can see that I just copied over the function that we had before. In the very beginning, we had our parsing function, I just copied it over from line five to line 13, I, guess or order. 12 just took that block, and now, if I have a string, which is a real monetary amount and I I call pars on it, then I can return automatically an element of type money. An object of type money that is super helpful because then we can do things like this.

A

You just call it on a string, and you see that : :, turbo fish, :, : angle bracket is called a Kluber fish and inside I define the type that I want and with this yeah I get something that which is very fluent to read: I, say: 100, euro dot, parse :, :, angle, bracket, money, : angle bracket and that's it, and so we took our initial code. We modified it based on the compilers input and then we reach something which is both readable, maintainable and safe without doing much.

A

So this is what I learned as a process in those last years, using rust start with something iterate and the compiler will help you a lot. So if you're interested in that kind of stuff check out my website and also ping me on Twitter, and please contribute to that list, maybe we can make it bigger and if you want somebody that can entitiy along then use the Clippy crate, which has a lot more links to help. You write more idea, magic code. Thank you.

A

The question was, since you cannot use the slice match with because it is a nightly. What would you use in stay with us? Well in stay with us? You can use what I showed you in the previous slide, which is just the explicit matching on the type.

A

What would also be nice in the future will be collecting into a tuple because we collected into a vector, and then we checked the elements of the vector, but this is not possible right now there will be a lot of those paper. Cuts will go away in the next year or two because there's an ergonomics initiative, and that means that all of those things they are right on the verge.

A

So you can expect this to become stable, very soon, I guess within this year, and then you will see the the rest of next year, probably will have even more patterns, and this is like a growing ecosystem and growing stack. So probably this list of idea, Matic things this will be longer and longer and longer and the things that I told you today might not be the things that you want to use in 10 years, but same with other languages. There are some paper cuts, I I admit, but we will get there in the end.