A Memory
Developers ask for the freedom to do whatever they want. Well, that's available; you can take it :). However, the question is, do we need it? Yes and No!
In the context of programming languages, C is considered the mother. In C and many other programming languages, we are free to do whatever we want. The generation that manually manages memory is responsible for keeping track of variable lifetimes and knowing when it's necessary to free the memory.
If you free the memory too soon, the variable becomes invalid. If you release the memory later, you waste space; if you forget altogether, you risk a memory overflow, leak, or crash.
What solutions did we come up with? Well, garbage collection took that weight off the shoulders of programmers, but at runtime cost. Other solutions were to implement standards or guidelines to follow when managing memory. An example of such a guideline is Resource Acquisition Is Initialisation (RAII) in C++, which we'll discuss later in this article.
Maybe a Force is Necessary?
What Rust does differently is to enforce rules of how Rust code is written so it is memory-safe. For the most part, you have no choice, and that discipline is good. We would eventually gear towards that direction anyway, so why not now?
The Rust developers named this type of memory management ownership.
What is Ownership?
Ownership is Rust's central feature, and it mainly operates by three rules that the compiler checks at compile time. As a result, no runtime costs are incurred for any ownership features.
It begins to make sense why Rust's build time takes longer than most but runs faster than most.
Before we look at the ownership rules, let's learn the issues that it is addressing:
Keeping track of what data is on the heap.
Minimising the amount of duplicate data on the heap.
Cleaning up unused data on the heap so we don't run out of memory.
A Crash Course on Stacks and Heap Memory
Because of the ownership rules, rust makes memory safety guarantees at compile time without needing a garbage collector.
The stack and heap are parts of the memory available for your code to use at runtime.
The stack stores values in the order it gets them and removes the values in opposite order [LIFO vibes]. The ownership rules are 'lighter' on stack memory because the size of items stored on it is fixed and known at compile time. The added advantage of data stored on the stack being close to each other makes it faster to access than the heap.
The heap is usually used for data unknown at compile time since their size is not fixed and can change during runtime. Like other languages, the actual data is stored in an allocated space on the heap, and a pointer to the data is stored on the stack.
Now, what are the ownership rules? It's simpler than you think :).
Simple doesn't mean easy.
The Ownership Rules
Each value in Rust has a variable called its owner.
There can be only one owner at one time.
When an owner goes out of scope, the value will be dropped.
Is Ownership RAII?
Resource Acquisition Is Initialisation (RAII) is a pattern of deallocating resources at the end of an item's lifetime.
Trust me, I don't know why RAII is called RAII :)
It's the concept that matters, so it's all good.
"Rust pairs exactly one allocate with exactly one free". Meaning that each memory allocation is followed by only one deallocation once the variable goes out of scope. It is this pattern that makes it similar to the RAII guidelines.
A scope is the range within a program for which an item is valid. You can say rust deallocated memory when a variable's lifetime is over.
Are ownership rules an implementation of RAII? I'll leave that to your judgement :)
Concluding Thoughts
Today's lessons seem very technical, and they are. Trying to explain every little detail will take a series of articles and a few coding demonstrations. If you are curious to learn more, you can always refer to The Rust Book. My 100 Days of Rust article series aims to share daily lessons :).
Yeah, I'm not done with chapter 4, but for now, I need to let the understanding of ownership sink in. Unfortunately, I have five submissions due this weekend. So, I'll need to pause this challenge, finish up my school responsibilities, and regroup on Monday :(
I also managed to complete a Celsius to Fahrenheit calculator yesterday. I'm happy with the progress so far.