Programming in Rust: the good, the bad, the ugly

Programming in Rust: the good, the bad, the ugly

Rust is a multi-paradigm system programming language focused on safety, especially safe concurrency. Rust is syntactically similar to C++, but is designed to provide better memory safety while maintaining high performance.

Rust is a multi-paradigm system programming language focused on safety, especially safe concurrency. Rust is syntactically similar to C++, but is designed to provide better memory safety while maintaining high performance.

Rust is a modern systems-level programming languagedesigned with safety in mind. It provides zero-cost abstractions, generics, functional features, and plenty more. I recently embarked on an effort to learn Rust properly, and I wanted to share some of my thoughts.

Until recently, I’d written only a handful of small programs in Rust, and after reading half of “Programming Rust”, I really didn’t know Rust. I figured a good way to get to know the language was to solve all **189 problems from the “Cracking the Coding Interview” **book. Not only would I solve them with Rust, but I decided to do it live on Twitch. I’m no stranger to giving tech talks, or coding in front of an audience, but trying to learn a programming language, and explain what I was doing–live for the world to see–was something new for me.

Things started off a bit rough: technical hiccups, stream issues, tooling problems, and I had difficulty understanding the memory paradigm at first. Trying to do that, while also explaining what I was doing to people, was uh…tricky.

It took me about 8 hours to implement a linked list: I recorded two 4 hour streams of myself trying to figure out how to properly use Rc, RefCell, and Box. For a while I felt like I was just banging on the keyboard trying random combinations until something stuck. What’s amazing is that people tuned in to watch. I must have been doing something right.

After a bit of reading offline (and followed the very helpful “Learning Rust With Entirely Too Many Linked Lists” book), and the concepts started to click for me. After finishing my linked list implementation, things got easier.

Linked list in Rust. VSCode has tight integration with RLS

I’m now into chapter 4 of the book, and I feel like I’ve hit my stride. Rust feels natural, productive, and extremely satisfying once it compiles. Rust is strongly typed and provides excellent compiler messages: if you managed to appease the compiler, there’s a good chance your code will work–barring any logic flaws.

One lovely feature of Rust is how helpful the compiler can be. Compiler messages for C++ code, for example, are notoriously difficult to decipher. While Clang has made massive strides with its error messages, Rust’s compiler is another order of magnitude more helpful.

Example of rustc’s error output

I’m going to summarize some of my findings thus far. This is based on my initial reactions, and I acknowledge my lack of Rust expertise, but it may still be interesting for others to see how their experience compares to mine. I woefully admit that I have not thoroughly researched every issue below, so I may have out of date or inaccurate information.

Language: The Good

First of all, kudos to the Rust team and everyone who has contributed to the project. This has been one of the most fun programming language learning experiences I’ve ever had. I don’t know if Rust will capture the mindshare of developers in the same way some other languages have, but I think it’s here to stay. On to the details:

  • Rust code is fairly easy to read, and doesn’t suffer from the hard to parse syntax of languages like C++ or Scala. It seems to have what I expect it to have, and the challenge is just in figuring out which function to call.
  • Having functional features like map(), filter(), find(), and so on are a delight. Defining higher order functions and passing closures to them is a breeze. It doesn’t make functional programming quite as easy as a language like Ruby, but it’s close. In fact, it’s amazing how easy it is for a language that performs comparably to C/C++.
  • Rust forces you to think hard about memory allocation, because you have no choice. In the end it means sloppy code is difficult to write, and good code is easy to write. These abstractions map directly to writing safe concurrent code as well.
  • Rust’s zero-cost abstractions make it easy to write good code without adding overhead. Traits provide modern programming abstraction without the performance penalty.
  • Rust code is safe (provided you don’t use the unsafe keyword, or call out to unsafe C libraries)
  • Rust’s Result and Option provide a good way for dealing with functions that might return a value, or variables that might contain a value. A common pattern in C, C++, and even Java is for functions to return a null pointer when there’s nothing to return. In most cases, when this happens unexpectedly, it results in someone having a bad time.

Language: The Bad

  • I find the need to unwrap(), as_ref() and borrow() a bit verbose at times. I wish there was some syntax sugar to cut down on the number of times I have to chain these calls together in different patterns. I find myself frequently writing code similar tooption.as_ref().unwrap().borrow(), which feels icky.
  • There are certain trade offs the compiler needs to make in order to be able to compile code within a reasonable amount of time. As a result, there are some cases where rustc can’t infer a type, or it needs some human assistance in order to compile the code. For me, I’ve found it can sometimes be really difficult to figure out what the compiler needs, and why it can’t figure it out for me.
  • Some things occasionally feel too verbose. For example, converting between str and String, or passing a reference instead of value to a function seems like something the compiler could figure out for me. I’m sure there’s a good reason for why it is the way it is, but it occasionally feels like rustc is being too correct.
  • Having to handle every Result from every function is good; it means the programmer has to think about what’s happening with every function call. Sometimes it feels tedious. The ? operator can cut down on some of the verbosity, but there’s no good generalize way for handling the failure types. Crates like failure and error-chain make this easier, but you still need to explicitly define a case for every type of error that may occur.

Language: The Ugly

  • Macros: WTF? Rust macros feel like a left turn compared to the rest of the language. To be fair, I haven’t been able to grok them yet, and yet they feel out of place like some strange bolt-on appendage, one which only came about after the language was designed, inspired by Perl. I will eventually take some time to understand them properly in the future, but right now I want to avoid them. Like the plague.

Tooling: The Good

  • Rust provides decent tooling, and integrates with IDEs like VSCode through RLS. RLS provides support for linting, code completion, syntax checking, and formatting on the fly.
  • Cargo is Rust’s powerful package manager: you’ll likely become familiar with it if you try Rust. For the most part, working with Cargo is a pleasure. There’s already a plethora of plugins for Cargo that provide additional features such as code coverage.
  • Cargo is also a build system, and it can be used to run unit and integration tests. Configuring your build and dependencies is a snap with its somewhat declarative TOML syntax.
  • Cargo integrates with crates.io which is the definitive source for open source Rust projects. Much like PyPi or RubyGems, you’ll find nearly all other Rust packages hosted on crates.io.
  • rustup is the preferred tool for managing your Rust installation. You can select stable, beta, or nightly channels, and install specific builds from all previous releases. It also lets you install components like clippy and rustfmt
  • clippy is a must have code linter if you’re a perfectionist like me. It will help you learn the Rust way, and it can catch many common mistakes that you might otherwise not notice. For me, clippy was helpful when I knew of a way to solve something, but I did not know the right way.
  • rustfmt is an opinionated code formatter for Rust. In my opinion, opinionated formatters are the way to go. There’s no arguing about code formatting when everything adheres to the same standard.
  • sccache, a compiler cache, will make things faster by reducing compile times. However — beware — sccache does not work with RLS, so you can’t use it with your IDE.

Tooling: The Bad

Okay, okay, before I go on about the problems with Rust, we should all acknowledge that this is a work in progress. The Rust tooling has come very far, very quickly, but I think it still has a long way to go. I’m going to highlight a few of the things that need improvement:

  • Compilation feels slow. Not only is it slow, but I find I often have to recompile packages. I understand the necessity, but it’s still annoying at times. sccache helps, but it still feels slow. There are some ways to mitigate this, such as using cargo check instead of cargo build.
  • RLS uses racer for code completion, and I find that it’s hit or miss at best (in VSCode at least). Often functions that I expect to have completions for don’t exist, and functions that don’t exist show up as completion options. I haven’t done thorough analysis, but the suggestions seem to be right only about 75% of the time. The cause of this may simply be due to the slowness of RLS.
  • No REPL: this may be unfair, since there’s no decent C++ REPL either, but a lot of languages come with a REPL these days. There’s an open issue on GitHub about this. A good REPL is not necessary, but would be helpful.

Tooling: The Ugly

  • RLS is slow, buggy, and crashy. For me, at least, I find that I frequently need to restart RLS within VSCode. RLS is a great tool, but it does feel like it’s beta at best. I find myself having to pause and wait for RLS to catch up so I can make sure I’m not writing bad code. Sometimes I think it would be better to simply disable RLS, write the code, and then try and compile it like in the olden days when I did all my coding in Vim. It’s almost as if RLS has become too much of a crutch, and more of a distraction.

Libraries: The Good

  • Surprisingly large number of available libraries in the Rust ecosystem. It seems as if there was a gold rush to run out and implement all the Rust libraries, and get your name immortalized in Rust history. You can find most of what you’d expect on crates.io or GitHub. I’m often surprised by how every search turns up 2 or 3 different implementations of what I’m looking for.
  • Most libraries I have used work as expected, and many have exceeded expectations. This is a subtle and important distinction from the alternative, which are libraries which do not work.

New York Public Library in 1908, from the Library of Congress

Libraries: The Bad

  • Although there are many libraries, I’ve found that a lot of them are incomplete, immature, or completely abandoned. The Rust community seems like it’s still in its early days, but it’s improving every day.
  • Sometimes there are…too many options. For example, I wanted to use a logging library, and I discovered that there is a long list of options to choose from. Having many options is fine, but for something like this I just want to be told what to use. The Java ecosystem has a similar issue with java.util.logging, log4j, logback, log4j2, slf4j, and tinylog. To this day I still don’t know which Java logging library is the right one to use. With Rust, I just decided to use env_logger because it’s the first option in the list.
  • While not as bad as the Node.js ecosystem, the list of dependencies for every library has become quite long. I wrote a small GitHub bot called LabHub, and I’m still surprised by how many dependencies get pulled in (181 crates, if you’re wondering). To me, this suggests fragmentation and duplication, which could perhaps be improved by slowly graduating some widely needed features into the standard library (something that C++ has done very slowly).

Libraries: The Ugly

  • I noticed that, along with a long list of dependencies for a relatively simple app, I was compiling different versions of the same libraries multiple times. I think Cargo is trying to be clever in order to maintain backward compatibility; it’s making guesses about which libraries to include based on semantic versioning. The thing that worries me about this is what happens when you have a library which depends on an ancient, broken version of some other library which also has a vulnerability. I have no doubt that the Rust authors have already considered this, but it still seems strange. To be fair, dealing with dependencies of dependencies is a very tricky problem. Thankfully there’s a tree tool for Cargo which can help sort these things out, and then you can force a dependency to upgrade its dependencies.

10 different libraries with 2 different versions in the same package

Final Thoughts

Rust is a great language. If programming is something you’re passionate about, please give it a shot. I hope you enjoy it.

Rust vs. Go: Should I Rust, or Should I Go

Rust vs. Go: Should I Rust, or Should I Go

Well both Rust and Go provide amazing performance. Should you write you’re next big thing with Rust or with Go? Go is fast and powerful, but it avoids bogging the developer down, focusing instead on simplicity and uniformity. Rust. If on the other hand, wringing out every last ounce of performance is a necessity, then Rust should be your choice. Rust is more of a competitor to C++ than it is with Go.

Should I stay, or should I go?” Great song by the band The Clash. I’m listening to it, right now, while I’m writing this article. The song debuted back in 1982, a long time ago. Back then, I was just a kid exploring a new hobby — programming my Atari 2600. The first video game I ever wrote was written using 6502 Assembly for that console. The compiler for it cost about $65, if I recall, which at the time equated to mowing ~13 or so lawns.

The game was simple: using the joystick, maneuver your spaceship through a randomly generated scrolling cave. The cave walls were sinusoidal, scrolling vertically on the left and right sides of the screen, and you had to make sure your craft didn’t crash into them. I know, I know: Not that sophisticated. But I was only ten or eleven years old at the time.

Despite the “power” of the processor, computing sine values at run-time was simply too much for it. So, using my handy Texas Instruments calculator, I pre-calculated a bunch of the sine values, carefully writing them down on paper, and then entering them in as constants for the game. This greatly enhanced the performance of the game, and made it usable.

So what’s my point? What’s any of this got to do with Rust or Go?

Today’s languages are far more advanced than 6502 Assembly, which make it easier to write complex programs. It took a lot of my time to write that game, and I could do it much faster today, with less code than I did back then. But which language today provides that magic combination of simplicity and power?

Well both Rust and Go provide amazing performance. They both compile to machine code, the Holy Grail of performance. And with today’s processing power, developers can do amazing things with either of these languages. So the question is: Should you write you’re next big thing with Rust or with Go?

With a quick search, you can easily find several articles that go into detail about the differences between the two languages. But the focus of this article is the bang for the buck, that magic combination of performance per line of code.

To put it another way, where is that sweet spot of simple code and top-end performance? And in this case, is it Rust, or is it Go?
There really isn’t any argument: Rust is faster than Go. In the benchmarks above, Rust was faster, and in some cases, an order of magnitude faster.

But before you run off choosing to write everything in Rust, consider that Go wasn’t that far behind it in many of those benchmarks, and it’s still much faster than the likes of Java, C#, JavaScript, Python and so on. So in other words, it’s almost a wash between Rust and Go on the axis of performance. Now, if what you’re building needs to wring out every last ounce of performance, then by all means, choose Rust. But if what you need is top-of-the-line performance, then you’ll be ahead of the game choosing either of these two languages.

So then we’re down to the complexity of the code. This is where things can be muddy since this can be more subjective than performance benchmarks. Let’s look at a simple exercise: building a small web server that prints out “Hello World” when it receives an HTTP request. To do this in Rust, it looks something like this:

use std::net::{TcpStream, TcpListener};
use std::io::{Read, Write};
use std::thread;


fn handle_read(mut stream: &TcpStream) {
    let mut buf = [0u8; 4096];
    match stream.read(&mut buf) {
        Ok(_) => {
            let req_str = String::from_utf8_lossy(&buf);
            println!("{}", req_str);
            },
        Err(e) => println!("Unable to read stream: {}", e),
    }
}

fn handle_write(mut stream: TcpStream) {
    let response = b"HTTP/1.1 200 OK\r\nContent-Type: text/html; charset=UTF-8\r\n\r\n<html><body>Hello world</body></html>\r\n";
    match stream.write(response) {
        Ok(n) => println!("Response sent: {} bytes", n),
        Err(e) => println!("Failed sending response: {}", e),
    }
}

fn handle_client(stream: TcpStream) {
    handle_read(&stream);
    handle_write(stream);
}

fn main() {
    let port = "8080";
    let listener = TcpListener::bind(format!("127.0.0.1:{}", port)).unwrap();
    println!("Listening for connections on port {}", port);

    for stream in listener.incoming() {
        match stream {
            Ok(stream) => {
                thread::spawn(|| {
                    handle_client(stream)
                });
            }
            Err(e) => {
                println!("Unable to connect: {}", e);
            }
        }
    }
}

Something pretty similar in Go looks like this:

package main

import (
	"fmt"
	"io"
	"log"
	"net/http"
)

type handler struct{}

func (theHandler *handler) ServeHTTP(writer http.ResponseWriter, request *http.Request) {
	log.Printf("Received request: %s\n", request.URL)
	log.Printf("%v\n", request)
	io.WriteString(writer, "Hello world!")
}

const port = "8080"

func main() {
	server := http.Server{
		Addr:    fmt.Sprintf(":%s", port),
		Handler: &handler{},
	}

	server.ListenAndServe()
}

Now, they are not 100% exactly the same, but they are close enough. The difference between them is ~20 lines of code. Rust definitely forces the developer to consider more, and thus write more code than Go.

Another example: Consider one of the more difficult aspects of software development: multi-threading. When tackling something like this, as you undoubtedly would when building an HTTP server, there’s a lot to think about:

  • You need to ensure everything you design is thread safe (locks)
  • You need to handle communication between threads (channels)
  • You have to design with concurrency and parallelism in mind (threads and routines)

Both Rust and Go handle these hurdles really efficiently, but Go requires less effort. With Rust, you have way more options, and thus more power, when spawning threads. Just look at some of the documentation on this. Here’s just one way to spawn a thread in Rust:

use std::thread;

let handler = thread::spawn(|| {
    // thread code
});

handler.join().unwrap();

On the other hand, here’s how to create something similar using Go:

go someFunction(args)

Another crucial part of writing code is handling errors. Here I think Rust and Go are quite similar. Rust enables the developer to handle errors cases through the use of the enum return types: Option<T>and Result<T, E>. The Option<T> will return either None or Some(T) whereas Result<T, E> will return either Ok(T) or Err(T). Given that most of Rust’s own libraries, as well as other third-party libraries, return one of these types, the developer will usually have to handle the case where nothing is returned, or where an error is returned.

Here’s a simple example of the Result type being returned by a function in Rust:

fn foo_divide(a: f32, b: f32) -> Result<f32, &'static str> {
    if b == 0.0 {
        Err("divide by zero error!")
    } else {
        Ok(a / b)
    }
}fn main() {
    match foo_divide(5.0, 4.0) {
        Err(err) => println!("{}", err),
        Ok(result) => println!("5 / 4 = {}", result),
    }
}

Notice that the Err case must be handled within the match statement.

Go, on the other hand, leaves this more up to the developer, since errors can be ignored using the _. However, idiomatic Go strongly recommends returning an error, especially since functions in Go can return multiple values. Therefore, it’s easy to have functions return their intended value along with an error, if there is one.

Here is the corresponding example from above done in Go:

func fooDivide(a float32, b float32) (float32, error) {
    if b == 0 {
        return 0, errors.New("divide by zero error!")
    }    return a / b, nil
}func main() {
    result, err := fooDivide(5, 4)
    if err != nil {
       log.Printf("an error occurred: %v", err)
    } else {
       log.Printf("The answer is: 5 / 4 = %f", result)
    }
}

Notice that this line:

result, err := fooDivide(5, 4)

could have been written as

result, _ := fooDivide(5, 4)

In the latter case, the error returned would have been ignored.

Honestly, they’re both pretty similar, except for Rust forcing error checking. Otherwise, there’s little difference, and it’s difficult to find an advantage one has over the other. To my eyes, this is a draw.

I could keep going, digging deeper into other language differences. But the bottom line, from threads, to channels, to generics, Rust provides the developer with more options. In this respect, Rust is closer to C++ than Go. Does this make Rust inherently more complex?

I think so, yes.

So here are my recommendations:

  • Either. If you’re building a web service that handles high load, that you want to be able to scale both vertically and horizontally, either language will suit you perfectly.
  • Go. But if you want to write it faster, perhaps because you have many different services to write, or you have a large team of developers, then Go is your language of choice. Go gives you concurrency as a first-class citizen, and does not tolerate unsafe memory access (neither does Rust), but without forcing you to manage every last detail. Go is fast and powerful, but it avoids bogging the developer down, focusing instead on simplicity and uniformity.
  • Rust. If on the other hand, wringing out every last ounce of performance is a necessity, then Rust should be your choice. Rust is more of a competitor to C++ than it is with Go. Having battled with C++, Rust feels just as powerful but with many happy improvements. Rust empowers developers to have control over every last detail of how their threads behave with the rest of the system, how errors should be handled, and even the lifetime of their variables!
  • Rust. Rust was designed to interoperate with C. Go can as well, but gives up a lot to achieve this goal, and it’s not really its focus.
  • Go. If readability is a requirement, go with Go. It’s far too easy to make your code hard for others to grok with Rust.

I hope you enjoyed reading this!

The Rust Programming Language - Understanding If in Rust

The Rust Programming Language - Understanding If in Rust

The Rust Programming Language - Understanding If in Rust. Rust’s take on if is not particularly complex, but it’s much more like the if you’ll find in a dynamically typed language than in a more traditional systems language. if is a specific form of a more general concept, the ‘branch’, whose name comes from a branch in a tree: a decision point, where depending on a choice, multiple paths can be taken.

Rust’s take on if is not particularly complex, but it’s much more like the if you’ll find in a dynamically typed language than in a more traditional systems language. So let’s talk about it, to make sure you grasp the nuances.

if is a specific form of a more general concept, the ‘branch’, whose name comes from a branch in a tree: a decision point, where depending on a choice, multiple paths can be taken.

In the case of if, there is one choice that leads down two paths:


# #![allow(unused_variables)]
#fn main() {
let x = 5;

if x == 5 {
    println!("x is five!");
}
#}

If we changed the value of x to something else, this line would not print. More specifically, if the expression after the if evaluates to true, then the block is executed. If it’s false, then it is not.

If you want something to happen in the false case, use an else:


# #![allow(unused_variables)]
#fn main() {
let x = 5;

if x == 5 {
    println!("x is five!");
} else {
    println!("x is not five :(");
}
#}

If there is more than one case, use an else if:


# #![allow(unused_variables)]
#fn main() {
let x = 5;

if x == 5 {
    println!("x is five!");
} else if x == 6 {
    println!("x is six!");
} else {
    println!("x is not five or six :(");
}
#}

This is all pretty standard. However, you can also do this:


# #![allow(unused_variables)]
#fn main() {
let x = 5;

let y = if x == 5 {
    10
} else {
    15
}; // y: i32
#}

Which we can (and probably should) write like this:


# #![allow(unused_variables)]
#fn main() {
let x = 5;

let y = if x == 5 { 10 } else { 15 }; // y: i32
#}

This works because if is an expression. The value of the expression is the value of the last expression in whichever branch was chosen. An if without an else always results in () as the value.

The Rust Programming Language - Understanding Ownership in Rust

The Rust Programming Language - Understanding Ownership in Rust

The Rust Programming Language - Understanding Ownership in Rust. Ownership is Rust's most unique feature, and it enables Rust to make memory safety guarantees without needing a garbage collector. Ownership is how Rust achieves its largest goal, memory safety. There are a few distinct concepts, each with its own chapter: ownership, borrowing and lifetimes ...

This is the first of three sections presenting Rust’s ownership system. This is one of Rust’s most distinct and compelling features, with which Rust developers should become quite acquainted. Ownership is how Rust achieves its largest goal, memory safety. There are a few distinct concepts, each with its own chapter:

  • ownership, which you’re reading now
  • borrowing, and their associated feature ‘references’
  • lifetimes, an advanced concept of borrowing

These three chapters are related, and in order. You’ll need all three to fully understand the ownership system.

Meta

Before we get to the details, two important notes about the ownership system.

Rust has a focus on safety and speed. It accomplishes these goals through many ‘zero-cost abstractions’, which means that in Rust, abstractions cost as little as possible in order to make them work. The ownership system is a prime example of a zero-cost abstraction. All of the analysis we’ll talk about in this guide is done at compile time. You do not pay any run-time cost for any of these features.

However, this system does have a certain cost: learning curve. Many new users to Rust experience something we like to call ‘fighting with the borrow checker’, where the Rust compiler refuses to compile a program that the author thinks is valid. This often happens because the programmer’s mental model of how ownership should work doesn’t match the actual rules that Rust implements. You probably will experience similar things at first. There is good news, however: more experienced Rust developers report that once they work with the rules of the ownership system for a period of time, they fight the borrow checker less and less.

With that in mind, let’s learn about ownership.

Ownership

Variable bindings have a property in Rust: they ‘have ownership’ of what they’re bound to. This means that when a binding goes out of scope, Rust will free the bound resources. For example:


# #![allow(unused_variables)]
#fn main() {
fn foo() {
    let v = vec![1, 2, 3];
}
#}

When v comes into scope, a new vector is created on the stack, and it allocates space on the heap for its elements. When v goes out of scope at the end of foo(), Rust will clean up everything related to the vector, even the heap-allocated memory. This happens deterministically, at the end of the scope.

We covered vectors in the previous chapter; we use them here as an example of a type that allocates space on the heap at runtime. They behave like arrays, except their size may change by push()ing more elements onto them.

Vectors have a generic type Vec<T>, so in this example v will have type Vec<i32>. We'll cover generics in detail in a later chapter.

Move semantics

There’s some more subtlety here, though: Rust ensures that there is exactly one binding to any given resource. For example, if we have a vector, we can assign it to another binding:


# #![allow(unused_variables)]
#fn main() {
let v = vec![1, 2, 3];

let v2 = v;
#}

But, if we try to use v afterwards, we get an error:

let v = vec![1, 2, 3];

let v2 = v;

println!("v[0] is: {}", v[0]);

It looks like this:

error: use of moved value: `v`
println!("v[0] is: {}", v[0]);
                        ^

A similar thing happens if we define a function which takes ownership, and try to use something after we’ve passed it as an argument:

fn take(v: Vec<i32>) {
    // What happens here isn’t important.
}

let v = vec![1, 2, 3];

take(v);

println!("v[0] is: {}", v[0]);

Same error: ‘use of moved value’. When we transfer ownership to something else, we say that we’ve ‘moved’ the thing we refer to. You don’t need some sort of special annotation here, it’s the default thing that Rust does.

The details

The reason that we cannot use a binding after we’ve moved it is subtle, but important.

When we write code like this:


# #![allow(unused_variables)]
#fn main() {
let x = 10;
#}

Rust allocates memory for an integer i32 on the stack, copies the bit pattern representing the value of 10 to the allocated memory and binds the variable name x to this memory region for future reference.

Now consider the following code fragment:


# #![allow(unused_variables)]
#fn main() {
let v = vec![1, 2, 3];

let mut v2 = v;
#}

The first line allocates memory for the vector object v on the stack like it does for x above. But in addition to that it also allocates some memory on the heap for the actual data ([1, 2, 3]). Rust copies the address of this heap allocation to an internal pointer, which is part of the vector object placed on the stack (let's call it the data pointer).

It is worth pointing out (even at the risk of stating the obvious) that the vector object and its data live in separate memory regions instead of being a single contiguous memory allocation (due to reasons we will not go into at this point of time). These two parts of the vector (the one on the stack and one on the heap) must agree with each other at all times with regards to things like the length, capacity, etc.

When we move v to v2, Rust actually does a bitwise copy of the vector object v into the stack allocation represented by v2. This shallow copy does not create a copy of the heap allocation containing the actual data. Which means that there would be two pointers to the contents of the vector both pointing to the same memory allocation on the heap. It would violate Rust’s safety guarantees by introducing a data race if one could access both v and v2 at the same time.

For example if we truncated the vector to just two elements through v2:


# #![allow(unused_variables)]
#fn main() {
# let v = vec![1, 2, 3];
# let mut v2 = v;
v2.truncate(2);
#}

and v were still accessible we'd end up with an invalid vector since v would not know that the heap data has been truncated. Now, the part of the vector v on the stack does not agree with the corresponding part on the heap. v still thinks there are three elements in the vector and will happily let us access the non existent element v[2] but as you might already know this is a recipe for disaster. Especially because it might lead to a segmentation fault or worse allow an unauthorized user to read from memory to which they don't have access.

This is why Rust forbids using v after we’ve done the move.

It’s also important to note that optimizations may remove the actual copy of the bytes on the stack, depending on circumstances. So it may not be as inefficient as it initially seems.

Copy types

We’ve established that when ownership is transferred to another binding, you cannot use the original binding. However, there’s a trait that changes this behavior, and it’s called Copy. We haven’t discussed traits yet, but for now, you can think of them as an annotation to a particular type that adds extra behavior. For example:


# #![allow(unused_variables)]
#fn main() {
let v = 1;

let v2 = v;

println!("v is: {}", v);
#}

In this case, v is an i32, which implements the Copy trait. This means that, just like a move, when we assign v to v2, a copy of the data is made. But, unlike a move, we can still use v afterward. This is because an i32 has no pointers to data somewhere else, copying it is a full copy.

All primitive types implement the Copy trait and their ownership is therefore not moved like one would assume, following the ‘ownership rules’. To give an example, the two following snippets of code only compile because the i32 and bool types implement the Copy trait.

fn main() {
    let a = 5;

    let _y = double(a);
    println!("{}", a);
}

fn double(x: i32) -> i32 {
    x * 2
}

fn main() {
    let a = true;

    let _y = change_truth(a);
    println!("{}", a);
}

fn change_truth(x: bool) -> bool {
    !x
}

If we had used types that do not implement the Copy trait, we would have gotten a compile error because we tried to use a moved value.

error: use of moved value: `a`
println!("{}", a);
               ^

We will discuss how to make your own types Copy in the traits section.

More than ownership

Of course, if we had to hand ownership back with every function we wrote:


# #![allow(unused_variables)]
#fn main() {
fn foo(v: Vec<i32>) -> Vec<i32> {
    // Do stuff with `v`.

    // Hand back ownership.
    v
}
#}

This would get very tedious. It gets worse the more things we want to take ownership of:


# #![allow(unused_variables)]
#fn main() {
fn foo(v1: Vec<i32>, v2: Vec<i32>) -> (Vec<i32>, Vec<i32>, i32) {
    // Do stuff with `v1` and `v2`.

    // Hand back ownership, and the result of our function.
    (v1, v2, 42)
}

let v1 = vec![1, 2, 3];
let v2 = vec![1, 2, 3];

let (v1, v2, answer) = foo(v1, v2);
#}

Ugh! The return type, return line, and calling the function gets way more complicated.

Luckily, Rust offers a feature which helps us solve this problem. It’s called borrowing and is the topic of the next section!