Ceci est une ancienne révision du document !
Okay rustafarians, we head back to Rust development as @Daredevil14 and Ellin complained about where Lucas’ rust blog went. It looks like you guys want more rust and less ‘security nonsense’. Firstly, do not neglect to read the above book. If you are a complete beginner to rust or even to programming, we got you covered here at FCM. These articles are not to replace the book mentioned above, think of it more as helpers along the way.
Since we received no feedback on this – other than the initial complaint about Lucas’s blog – we have decided to retire this one.
From next issue onward, we will try something different.
When you need several instructions performed one after another, we put them into a function. You have seen functions from the start, as main() is a function. Functions take the form of: fn name(arguments), and, to call said function, you use it without the fn part. So far, we have used the main function only and no user-defined functions. Functions don’t have to just print something on the screen, like we have been doing, but functions can take arguments and return values. However, unlike C, or other older programming languages, you do not have to specify FIRST what you expect back, but you use an arrow to tell it what the output should be. It should look something like this:
fn average(x: i32, y: i32, z: i32 ) → i32
Note that the arrow is not ‘⇒’ like we used before. But that is also not where the odd things end; if you want to return a value, you do not end the statement with a semicolon.
Those trip me up, though if you think about it, makes perfect sense. I know we are hopping back to 3.3 in the book, but I thought it was important to point it out, as it is mentioned, but often overlooked. Now we can move on to part 7. In the beginning, when crates were mentioned, I thought of them as packages. But in Rust, we need to be clear: A package is one or more crates that provide a set of functionality. A package contains a ‘cargo.toml’ file that describes how to build those crates.
You will notice that the book refers us back to chapter 2, where we used the ‘rand’ crate, for random numbers. TL;DR we had to add a [dependencies] section and add rand. We also needed to build our file to reflect the changes with: ‘cargo build’. We used the random generator with ‘use rand::Rng’. However, as I understand it, it is better to add the crate right at the beginning. Simply add: ‘extern crate rand;’ before you use it as above. Now, obviously crates.io is not the be-all and end-all of crates, as you can roll your own. Noobs like me get tripped up on this one, as our [dependencies] section now needs to contain the path to our home-rolled crate. In Linux, we use ./ for the same directory and ../ for the directory above, so triple-check your paths before building! Because rust’s error output is so nice and verbose, we should catch this immediately, so build it without specifying the path, to see what the error looks like, and this will help you in the future when you are trying to figure out what went wrong. The great chess players do not only think about moves, but study patterns on the board, that is how they become great. You too will become a great programmer if you can spot an error and immediately recognise it and know how to remedy it.
Speaking of errors, do section 7.3, to catch that error. Now, when you head to section 7.4, you may be disgusted that they mention the ‘use’ keyword only now, after you have typed so many paths and double-colons you get nightmares about it. That is the reason I mention it now so you do not skip anything in section 7.4. On that note, the book does refer you to chapter 14, cargo workspaces. I suggest that if you are a noob, do not jump here, you need to have worked your way through at least chapter 12, before attempting chapter 14.
Let us quickly talk about ownership and borrowing. This is one of the legs that Rust stands on. Grasping this will help you a lot. Lots of programming of non-trivial programs will have you getting data, manipulating that data in some way, then outputting the result. This book in your web browser is a nice example. When you click on the link to chapter 14, it figures out where that page is stored, grabs the data and displays it in your browser. The speed of data is usually connected to where it is stored. If your data is on the internet, like a web page, it is slow as it needs to be lifted from long-term memory (disk) to short-term memory (ram), and then sent over the network. If your data is local, it just needs to do the first two steps and if it is in memory, that is only one step. Reading from disk is slower than reading from memory. Speed is not the only consideration here, space is another. Google has millions of gigabytes to store data on. Your hard drive may have only thousands of gigabytes and your memory in the tens column. So, as the speed increases, it becomes necessary to manage the space as you do not have an infinite amount. We can look into the concepts of ownership and borrowing if there is interest, but this is a good topic for you to read up on in your favourite browser as it is covered in section 4, but I suggest adding another source to get a different perspective.
That’s it for now. Next issue we will look at other things.
As always, if you need to reach us: misc@fullcirclemagazine.org