So what are regular pointers? Regular pointers (just called “pointers”) are variables that hold memory addresses as their values. They allow programs to store, read, and write data to memory locations with their addresses.

Here’s a diagram to give an idea of what they are:

In programming languages like C, C++, and Rust, pointers are useful for accessing manually allocated memory, but they come with these limitations:

• The memory address that a pointer holds can be deallocated while the pointer still references it, making it a dangling pointer.

• The pointer doesn’t help with managing the memory allocation, which can cause memory leaks or other types of memory bugs in cases where handling memory allocations are complex.

Rust doesn’t give the same level of control of pointers as with C and C++. However, like C++, Rust provides smart pointers that overcome the limitations of regular pointers while providing extra functionalities.

In Rust, there are four major types of smart pointers: Box, Rc, Arc, and Weak. I’ll be discussing them in this article. I’ll also touch a little on RefCell, because it adds a specific functionality that is missing in other smart pointers.

Table of Contents

• Box Pointers

• Rc and Arc Pointers

• Weak Pointers

• RefCell

• Summary

Box Pointers

Box is the most straightforward type of a smart pointer. It allows you to manually allocate memory in the heap.

#[allow(dead_code)]
#[derive(Debug)]
struct Point {
    x: f32,
    y: f32,
}

fn main() {
    let point = Box::new(Point { x: 0.0, y: 0.0 });
    println!("{:?}", point);
}

You can access the contents of a Box pointer like you would with a regular variable:

println!("{}", point.x); // -> output: 0.0
println!("{}", point.y); // -> output: 0.0

It works almost identically to malloc in C and new in c++, with the exception that Box automatically gets freed when it goes out of scope, or when the program execution ends, as opposed to manually freeing the allocation in malloc and new.

Rc and Arc Pointers

I’m putting Rc and Arc together because they’re very similar in what they do and how they work.

Rc and Arc are reference counted pointers that allow multiple ownership of a memory allocation. Similar to Box, they allocate memory in the heap, but what differentiates them from Box is that they also include a reference count.

Rc and Arc allows you to create multiple clones of a reference to a memory allocation. This allows you to move those references to multiple scopes, and in the case of Arc, multiple threads, without borrowing. For example:

use std::sync::Arc;
use std::thread;
use std::thread::JoinHandle;

struct GameState {
    user_name: String,
}

impl GameState {
    fn new() -> Self {
        GameState { user_name: "Chigozie".to_string() }
    }
}

fn main() {
    let mut threads: Vec<JoinHandle<()>> = vec![];
    let game_state = Arc::new( GameState::new() );

    let g1 = Arc::clone(&game_state); // first clone
    threads.push(thread::spawn(move || {
        let username = &g1.user_name;
        // ...
    }));

    let g2 = Arc::clone(&game_state); // second clone
    threads.push(thread::spawn(move || {
        let username = &g2.user_name;
        // ...
    }));

    let g3 = Arc::clone(&game_state); // third clone
    threads.push(thread::spawn(move || {
        let username = &g3.user_name;
        // ...
    }));

    let g4 = Arc::clone(&game_state); // fourth clone
    threads.push(thread::spawn(move || {
        let username = &g4.user_name;
        // ...
    }));

    let g5 = Arc::clone(&game_state); // fifth clone
    threads.push(thread::spawn(move || {
        let username = &g5.user_name;
        // ...
    }));

    for th in threads {
        th.join().unwrap();
    }
}

In this example, I created an instance of a game struct in an Arc data structure, spawned five threads, then created and passed five more Arc references of the game struct to the five spawned threads.

The difference between Rc and Arc pointers is that references in Arc pointers are counted atomically, while references in Rc pointers are counted using the usual mathematical operations. This means that the operations that go into counting the references in Arc pointers are guaranteed to not be interrupted or overlapped by other threads or processes, making them very useful for multi-threaded environments.

One useful application of Rc and Arc pointers is in reference-based data structures, like linked lists, where each node has its value and a reference to the next node. For example:

use std::rc::Rc;

#[derive(Debug)]
struct Node {
    value: i32,
    next: Option<Rc<Node>>,
}

fn main() {
    // A chain of nodes
    let node1 = Rc::new(Node { value: 1, next: None });
    let node2 = Rc::new(Node { value: 2, next: Some(Rc::clone(&node1)) });
    let node3 = Rc::new(Node { value: 3, next: Some(Rc::clone(&node2)) });

    // Multiple owners of node2
    let another_ref_to_node2 = Rc::clone(&node2);

    println!("Node 3: {:?}", node3);
    println!("Another reference to Node 2: {:?}", another_ref_to_node2);
}

The memory allocations pointed to by Rc and Arc references are dropped when their reference counts goes to 0. The reference count of Rc and Arc pointers goes to 0 when it and all its clones have gone out of scope, or have been dropped manually.

Weak Pointers

Unlike Arc or Rc pointers, Weak pointers are non-owning references to memory allocations. This means that they don’t count towards ownership of the memory allocation and don’t stop memory allocations from being dropped.

Weak references are helpful in scenarios where you might prefer a reference to a memory allocation to prevent it from being deallocated. A good example of a scenario like this is a doubly linked list, where each node holds a reference to the next node and the previous node:

A scenario like this using Rc or Arc for both the next and previous nodes can cause reference cycles. Reference cycles prevent nodes from being deallocated because for one node to be deallocated all Arc or Rc references to it must be 0. Since the nodes in this case hold references to other nodes that also hold references back to it, both nodes can’t be deallocated automatically and they can end up stopping all other nodes in the data structure from being deallocated, causing a memory leak.

To prevent reference cycles while allowing nodes to both reference previous and next nodes, you can make each node’s reference to its previous node a Weak reference. For example:

use std::rc::{Rc, Weak};
use std::cell::RefCell;

#[derive(Debug)]
struct Node {
    value: i32,
    next: Option<Rc<RefCell<Node>>>,
    prev: Option<Weak<RefCell<Node>>>, // Weak reference to avoid cycles
}

fn main() {
    let node1 = Rc::new(RefCell::new(Node { value: 1, next: None, prev: None }));
    let node2 = Rc::new(RefCell::new(Node { value: 2, next: None, prev: Some(Rc::downgrade(&node1)) }));

    // Set node1's next to node2
    node1.borrow_mut().next = Some(Rc::clone(&node2));

    println!("Node 1: {:?}", node1);
    println!("Node 2: {:?}", node2);
}

However, since Weak references have non-owning references to memory allocations, they need to be upgraded to Rc or Arc references with .upgrade() to allow access to the memory allocation they point to.

Also, as you can see in code example below (as well as above on line 13), Rc and Arc references can be downgraded to Weak references with Rc::downgrade() or Arc::downgrade():

use std::rc::{Rc, Weak};

fn main() {
    let strong = Rc::new(5);
    let weak = Rc::downgrade(&strong);

    // Drop the weak reference
    drop(weak);

    // try to upgrade the weak reference
    if let Some(shared) = weak.upgrade() {
        println!("Data is still alive: {}", shared);
    } else {
        println!("Data has been dropped");
    }
}

Running this results in the following output:

Data has been dropped

This shows that only having weak references to a memory allocation doesn’t prevent it from being dropped. If a Weak pointer’s memory allocation is dropped, calling .upgrade() on the Weak pointer would return None.

RefCell

To ensure memory safety, Rust doesn’t allow you to mutate the data that smart pointers point to. This can prevent hidden mutations, but can become really inconvenient when you need to build something that is dynamically changing (for example the ability to add a new node to anywhere in a linked-list data structure).

RefCell allows you to overcome this limitation because it is a data structure that allows interior mutability of immutable variables by enforcing Rust’s borrowing rules at runtime.

You may have noticed it’s usage in the Weak pointer example earlier:

use std::rc::{Rc, Weak};
use std::cell::RefCell;

#[derive(Debug)]
struct Node {
    value: i32,
    next: Option<Rc<RefCell<Node>>>,
    prev: Option<Weak<RefCell<Node>>>,
}

fn main() {
    let node1 = Rc::new(RefCell::new(Node { value: 1, next: None, prev: None }));
    let node2 = Rc::new(RefCell::new(Node { value: 2, next: None, prev: Some(Rc::downgrade(&node1)) }));

    // Set node1's next to node2
    node1.borrow_mut().next = Some(Rc::clone(&node2));

    println!("Node 1: {:?}", node1);
    println!("Node 2: {:?}", node2);
}

You can call .borrow() and .borrow_mut() on a RefCell type to borrow references to its internal value at runtime, while keeping its own type as immutable making it useful in cases like this that require immutability.

Mutable and immutable borrows in a RefCell type work just like regular borrows that are checked at compile time, but they allow you to bypass compile time restrictions to be checked instead at runtime.

One major borrowing rule to look out for is the “single mutable ownership and multiple immutable ownership” rule. Borrowing two mutable references to a RefCell would result in a panic, crashing the application. For example:

#![allow(unused_variables)]
#![allow(dead_code)]
#![allow(unused_mut)]
use std::cell::RefCell;

fn main() {
    let counter = RefCell::new(100);
    let mut c1 = counter.borrow_mut();
    let mut c2 = counter.borrow_mut();

    println!("I'm done");
}

/**
 * output:
 *  thread 'main' panicked at src/main.rs:9:26:
 *  already borrowed: BorrowMutError
 *  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
 */

Summary

To give an overview of the points made in this article, there are four common types of smart pointers in Rust:

• Box is used for manually allocating memory in the heap (similar to malloc and new in C and C++ respectively)

• Rc and Arc are used for allowing multiple ownership of a memory allocation. Arc is best for multi-threaded environments, and Rc is best for single-threaded environments.

• Weak is best used in giving multiple ownership of a memory allocation while preventing reference cycles.

• RefCell allows mutability in scenarios that require immutability, for example, in smart pointers.

I hope this article has provided clarity on smart pointers in Rust and how they work. Thanks for reading!

Even though they are important to Rust projects, lifetimes can be quite tricky to wrap your head around. So I created this guide to provide more clarity on what they are and when you should use them.

Prerequisites for this Tutorial

To get the most out of this tutorial, you'll need the following:

• At least beginner-level familiarity with Rust: This tutorial doesn't help with learning how to code in Rust. It only helps with understanding lifetimes in Rust and how they work

• Familiarity with generics: Generics in Rust work identically to how they do in popular programming languages. Knowledge of how generics work in any language would be helpful.

• Knowing how the borrow checker works isn't as much a requirement as the last two above, but it would be helpful. Knowledge of how lifetimes work also helps in understanding how the borrow checker works.

So, What are Lifetimes in Rust?

For Rust's borrow checker to ensure safety throughout your code, it needs to know how long all the data in the program will live during its execution. This becomes difficult to do in certain situations, and those situations are where you need to use explicit lifetime annotations.

Lifetimes in Rust are mechanisms for ensuring that all borrows that occur within your code are valid. A variable's lifetime is how long it lives within the program's execution, starting from when it's initialized and ending when it's destroyed in the program.

The borrow checker can detect the lifetimes of variables in many cases. But in cases where it can't, you have to assist it with explicit lifetime annotations.

The syntax for explicit lifetime annotations is a single quote followed by a set of characters for identification (for example, 'static, 'a) as in:

max<'a>

The lifetime annotation indicates that max should live at most as long as 'a.

Using multiple lifetimes follows the same syntax:

max<'a, 'b>

In this case, the lifetime annotations indicate that max should live at most as long as 'a and 'b.

Explicit lifetime annotations are handled similarly to how generics are. Let's take a look at an example:

fn max<'a>(s1: &'a str, s2: &'a str) -> &'a str {
    // return the longest string out of the two
}

In the example, the lifetime annotations indicate that max should live at most as long as the lifetimes of s1 or s2. It also indicates that max returns a reference that lives as long as s1.

A Rust project has many cases that would require explicit lifetime annotations, and in the next few sections, we'll go over each of them.

Lifetime Annotations in Functions

A function only needs an explicit lifetime annotation when it returns a reference from any of its arguments. Let's take an example:

fn max<'a>(s1: &'a str, s2: &'a str) -> &'a str {
    if s1.len() > s2.len() {
        s1
    } else {
        s2
    }
}

If you remove the lifetime annotations, you'll get an LSP (Language Server Protocol) warning to include the lifetime annotations. If you ignore LSP's warning message and compile the code, you'll get the same message as a compiler error. For example:

fn max(s1: &str, s2: &str) -> &str {
    if s1.len() > s2.len() {
        s1
    } else {
        s2
    }
}

/**
 * Output ->
 *
error[E0106]: missing lifetime specifier
  --> src/main.rs:44:31
   |
44 | fn max(s1: &str, s2: &str) -> &str {
   |            ----      ----     ^ expected named lifetime parameter
   |
   = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `s1` or `s2`
help: consider introducing a named lifetime parameter
   |
44 | fn max<'a>(s1: &'a str, s2: &'a str) -> &'a str {
   |       ++++      ++           ++          ++

For more information about this error, try `rustc --explain E0106`.
error: could not compile `lifetime-test` (bin "lifetime-test") due to 1 previous error
 ***********************
 */

On the other hand, a function doesn't need explicit lifetimes if it isn't returning a reference in its arguments. For example:

fn print_longest(s1: &str, s2: &str) {
    if s1.len() > s2.len() {
        println!("{s1} is longer than {s2}")
    } else {
        println!("{s2} is longer than {s1}")
    }
}

A function returning a different value doesn't need explicit lifetime annotations either:

fn join_strs(s1: &str, s2: &str) -> String {
    let mut joint_string = String::from(s1);
    joint_string.push_str(s2);
    return joint_string;
}

You only need to specify lifetimes if a function returns a reference from one of its arguments that is a borrowed reference.

Lifetime Annotations in Structs

Structs require explicit lifetime annotations when any of their fields are references. This allows the borrow checker to ensure that the references in the struct's fields live longer than the struct. For example:

struct Strs<'a, 'b> {
    x: &'a str,
    y: &'b str,
}

Without the lifetime annotations, you'll get a similar LSP and compiler error message to the one in the previous section:

struct OtherStruct {
    x: &str,
    y: &str,
}

/**
* Output ->
**********************
error[E0106]: missing lifetime specifier
 --> src/main.rs:7:8
  |
7 |     x: &str,
  |        ^ expected named lifetime parameter
  |
help: consider introducing a named lifetime parameter
  |
6 ~ struct OtherStruct<'a> {
7 ~     x: &'a str,
  |

error[E0106]: missing lifetime specifier
 --> src/main.rs:8:8
  |
8 |     y: &str,
  |        ^ expected named lifetime parameter
  |
help: consider introducing a named lifetime parameter
  |
6 ~ struct OtherStruct<'a> {
7 |     x: &str,
8 ~     y: &'a str,
  |

For more information about this error, try `rustc --explain E0106`.
error: could not compile `lifetime-test` (bin "lifetime-test") due to 2 previous errors
**********************
*/

Lifetime Annotations in Methods

Lifetime annotations concerning methods can be done as annotations to standalone methods, impl blocks, or traits. Let's look at each of them:

Standalone Methods:

Annotating lifetimes on standalone methods is identical to annotating lifetimes in functions:

impl Struct {
    fn max<'a>(self: &Self, s1: &'a str, s2: &'a str) -> &'a str {
        if s1.len() > s2.len() {
            s1
        } else {
            s2
        }
    }
}

impl Blocks

Writing explicit lifetime annotations for impl blocks is required if the struct it is associated with has lifetime annotations in its definition. This is the syntax for writing impl blocks with explicit lifetime annotations:

struct Struct<'a> {
}

impl<'a> Struct<'a> {
}

This allows any method you write in the impl block to return a reference from Struct. For example:

struct Strs<'a> {
    x: &'a str,
    y: &'a str,
}

impl<'a> Strs<'a> {
    fn max(self: &Self) -> &'a str {
        if self.y.len() > self.x.len() {
            self.y
        } else {
            self.x
        }
    }
}

Traits

Lifetime annotations in traits are dependent on the methods that the trait defines.

Let's look at one example. A method inside a trait definition can use explicit lifetime annotations as a standalone method, and the trait definition won't require explicit lifetime annotations. Like so:

trait Max {
    fn longest_str<'a>(s1: &'a str, s2: &'a str) -> &'a str;
}

impl<'a> Max for Struct<'a> {
    fn longest_str(s1: &'a str, s2: &'a str) {
        if s1.len() > s2.len() {
            s1
        } else {
            s2
        }
    }
}

If a trait method requires references from the struct its associated with, the trait's definition would require explicit lifetime annotations. For example:

trait Max<'a> {
    fn max(self: &Self) -> &'a str;
}

Which can be implemented this way:

struct Strs<'a> {
    x: &'a str,
    y: &'a str,
}

trait Max<'a> {
    fn max(self: &Self) -> &'a str;
}

impl<'a> Max<'a> for Strs<'a> {
    fn max(self: &Self) -> &'a str {
        if self.y.len() > self.x.len() {
            self.y
        } else {
            self.x
        }
    }
}

Lifetime Annotations in Enums

Similar to structs, enums need explicit lifetime annotations if any of their fields are references. For example:

enum Either<'a> {
    Str(String),
    Ref(&'a String),
}

The 'static Lifetime

In many Rust projects, you'll likely have encountered variables that are 'static in lifetimes. In this section, we'll go over a brief overview of what a 'static lifetime is, how it works, and where it is commonly used.

'static is a reserved lifetime name in Rust. It signifies that the data that a reference points to lives from where it is initialized to the end of the program. This differs slightly from static variables, which are stored directly in the program's binary file. However, all static variables have a 'static lifetime.

Variables with 'static lifetimes can be created at runtime. But they can't be dropped, only coerced into shorter lifetimes. For example:

// The lifetime annotation 'a is the shorter lifetime of the
// two arguments s1 and s2
fn max<'a>(s1: &'a str, s2: &'a str) -> &'a str {
    if s1.len() > s2.len() {
        s1
    } else {
        s2
    }
}

fn main() {
    let first = "First string"; // Longer lifetime

    {
        let second = "Second string"; // Shorter lifetime

        // In the max function, the lifetime of first is
        // coerced into the lifetime of second
        println!("The biggest of {} and {} is {}", first, second, max(first, second));
    };
}

String literals are examples of values with 'static lifetimes. They are also stored in the program's binary file and can be created at runtime.

Rust allows you to declare static variables with the static keyword, using this syntax:

static IDENTIFIER: &'static str = "value";

Static variables can be declared in any scope, including the global scope. This means that you can use static variables as global variables. For example:

static FIRST_NAME: &'static str = "John";
static LAST_NAME: &'static str = "Doe";

fn main() {
    println!("First name: {}", FIRST_NAME);
    println!("Last name: {}", LAST_NAME);
}

Static variables can also be mutable or immutable. But working with mutable static variables is only allowed in unsafe blocks because they're unsafe.

static mut FIRST_NAME: &'static str = "John";
static LAST_NAME: &'static str = "Doe";

fn main() {
    unsafe {
        println!("First name: {}", FIRST_NAME);
    }
    println!("Last name: {}", LAST_NAME);
    unsafe {
        FIRST_NAME = "Jane";
        println!("First name changed to: {}", FIRST_NAME);
    }
}

Summary

Lifetimes in Rust help the borrow checker ensure that all borrowed references are valid. The borrow checker can detect the lifetimes of variables in many cases, but in cases where it can't you have to assist it with explicit lifetime annotations.

Explicit lifetime annotations are those 'a, 'b, and 'static things you see in many Rust projects. You only need to use them in structures (structs, enums, traits, and impls) that deal with references, and in functions or methods that receive and return references.

In this guide, you learned about explicit lifetime annotations and saw some examples of how to use them. I it gave you some clarity on the topic, and helped you understand lifetimes better.

Thanks for reading!

In this article, I'll give you a simple overview of how asynchronous programming works in Rust. You'll learn about futures as well as async/.await.

This article isn't a beginner's guide to Rust or asynchronous programming, so you'll need to have some experience with programming in Rust and familiarity with asynchronous programming to get the most out of this guide.

With that said, let's begin!

When Should You Use Asynchronous Programming?

Asynchronous tasks work like a more integrated version of threads. You can use them in a lot of the same scenarios where you can use multiple threads. The benefits async programming provides over multiple threads is that multi-threaded applications have a larger overhead to work on multiple tasks compared to asynchronous applications.

But this doesn’t make asynchronous applications better than multithreaded applications. Multi-threaded programs can run multiple computing-intensive tasks simultaneously – and multiple times faster than if you ran all the tasks in a single thread.

With asynchronous coding, trying to run multiple computing-intensive applications simultaneously will be much slower than just running every task on a single thread.

Asynchronous programming is very good for building applications that make many network requests or many IO operations like file reading and writing.

I can’t cover every case when you’ll want to use asynchronous techniques. But I can say that it’s most beneficial for tasks that have a lot of idle time (for example, waiting for a server to respond to a network request).

During the idle time of an asynchronous task, instead of blocking the thread, the event handler works on other tasks in the program until the asynchronous task is ready to make progress.

Overview of Asynchronous Rust – Futures

The basics of asynchronous Rust are Futures. Futures are similar to promises in JavaScript. They are Rust's way of saying "hey, I'm going to give you the result later, but just hold on to this (the future instance) to keep track of if the result is ready."

Futures are traits, with a poll state that is either Poll::Pending to signify that the future is in the process of executing its task, or Poll::Ready to signify that the future is done with its task.

Futures are lazy. They run when you .await them (we'll look into how to .await them in the next section). .awaiting a future pauses the execution of an asynchronous thread, and begins running its task. At this point the result of the poll method is Poll::Pending. When the future is done with its task, poll's state will become Poll::Ready, and the future will allow it's thread to proceed.

If you want to get more into the technical details about Futures, you can check out the documentation.

async/.await in Rust

async and .await are the primary ways you'll be working with asynchronous code in Rust. async is a keyword for declaring asynchronous functions. Within those functions, the .await keyword pauses its execution until the result of the future is ready.

Let's take a look at an example:

async fn add(a: u8, b: u8) -> u8 {
    a + b
}

async fn secondFunc() -> u8 {
    let a = 10;
    let b = 20;
    let result = add(a, b).await;
    return result;
}

Any asynchronous function declared with async fn wraps its return value in a future. On the third line of secondFunc, we .await the future from add(a, b) to get its result before proceeding to return it.

How to Work with Asynchronous Operations in main

Rust doesn’t allow you to async fn main functions. Running asynchronous operations from a non-asynchronous function may lead to some operations not fully concluding before the main thread is exited.

In this section, we’ll look at two ways solve this issue. The two ways to do this are with futures and tokio. Let's look at both.

tokio

tokio is a platform that provides tools and APIs for performing asynchronous applications. tokio also allows you to easily declare an asynchronous main function, which will help with the issue I described earlier.

To install tokio in your project, add this line to its Cargo.toml:

[dependencies]
tokio = { version = "1", features = ["full"] }

After adding the line, you can write your main functions like this:

async fn add(a: u8, b: u8) -> u8 {
    a + b
}

#[tokio::main]
async fn main() {
    let a = 10;
    let b = 20;
    let result = add(a, b).await;
    println!("{result}");
}

The futures library

futures is a library that provides methods for working with asynchronous Rust. For our use case, futures provides futures::executor::block_on(). This method works similar to .await in asynchronous functions. It blocks the main thread, until the result of future is ready. futures::executor::block_on() also returns the result of the completed future.

To install futures in your project, add this line to its Cargo.toml:

[dependencies]
futures = "0.3"

After installing the library, you can do something like this:

use futures::executor::block_on;

async fn add(a: u8, b: u8) -> u8 {
    a + b
}

fn main() {
    let a = 10;
    let b = 20;
    let result = block_on(add(a, b));
    println!("{result}"); 
}

First, we import the block_on method on the first line and use the method to block the main thread until the result of the add(a, b) function was ready. We also didn’t have to make the main function asynchronous like we did with tokio.

Conclusion

Asynchronous programming allows you to run operations in parallel and with less overhead and complexity compared to traditional multi-threading. In Rust, it allows you to build I/O and network applications more efficiently.

While this article should help you become familiar with the basics asynchronous programming in Rust, it’s still just an overview. There are some cases where you'll need to use other constructs in Rust like Pinning, Arcs, and so on.

If you have any questions or thoughts, feel free to reach out to me. Thanks for reading!

For Rust programmers, MongoDB provides an excellent option for storing and retrieving data in a fast, efficient, and reliable way.

Rust is a modern, high-performance systems programming language that was designed for speed, safety, and concurrency. It is well suited for building high-performance, low-level software, and is becoming increasingly popular among developers.

In this article, we will explore how Rust programmers can leverage MongoDB to build high-performance, scalable applications. I will explain how to set up a MongoDB database, and show you how to interact with MongoDB from Rust using the official MongoDB Rust driver.

Whether you are new to MongoDB or an experienced Rust programmer looking to leverage this powerful database technology, this article will provide you with the knowledge and skills you need to get started.

Prerequisites

To follow along with the article, you only need the following:

• Knowledge of Rust.
• A system to work with.
• Rust installed on your system.

Getting Started

To get started with MongoDB, you will need to install the MongoDB Community Edition database software. The following steps will guide you through the installation process.

Download MongoDB Community Edition.

The first step is to download the MongoDB Community Edition package for your operating system.

You can download the package from the official MongoDB website at https://www.mongodb.com/try/download/community.

Install MongoDB Community Edition.

After downloading the package, run the installer and follow the prompts to install MongoDB Community Edition on your system.

Start the MongoDB server.

Once the installation is complete, start the MongoDB server by running the following command:

mongod

This will start the MongoDB server and it will be listening on port 27017 by default.

Install MongoDB Compass

MongoDB Compass is a graphical user interface (GUI) for working with MongoDB. It provides a simple and intuitive way to interact with MongoDB databases, collections, and documents.

To install MongoDB Compass, follow these steps:

1. Go to the official MongoDB website at https://www.mongodb.com/products/compass and download the appropriate version for your operating system.
2. Run the installer and follow the prompts to install MongoDB Compass on your system.
3. Once the installation is complete, launch MongoDB Compass and connect to your MongoDB server by entering the connection string in the connection dialog.

Congratulations, you have now installed the MongoDB Community Edition and MongoDB Compass. You can now start working with MongoDB databases, collections, and documents.

In the next section, we will cover how to set up a project so that you can interact with the database from Rust.

How to Set Up Your Project

Now that you have MongoDB installed on your system, it's time to set up your Rust project to use the official MongoDB Rust driver. Follow these steps to get started:

Create a new Rust project.

Open your terminal and create a new Rust project by running the following command:

cargo new myproject

This will create a new Rust project with the name "myproject".

Add the MongoDB Rust driver dependency.

Open the Cargo.toml file in your project directory and add the following dependency to it:

[dependencies]
mongodb = "2.3.1"

This will add the MongoDB Rust driver dependency to your project.

Import the necessary libraries.

Open the src/main.rs file in your project directory and import the necessary libraries by adding the following lines to the top of the file:

extern crate mongodb;
use mongodb::bson::doc;
use mongodb::{Client, options::ClientOptions};

This will import the doc macro, and the Client and ClientOptions types from the MongoDB Rust driver.

Connect to your MongoDB server.

Add the following code to your main function to connect to your MongoDB server:

let client_options = ClientOptions::parse("mongodb://localhost:27017").await.unwrap();
let client = Client::with_options(client_options).unwrap();

This will create a new ClientOptions object with the connection string to your MongoDB server. Then create a new Client object with the ClientOptions object.

Congratulations, you have now set up your Rust project to use the official MongoDB Rust driver.

In the next sections, we will cover how to create a database using MongoDB compass.

How to Create a Database in MongoDB

Before you can create a collection in MongoDB, you need to have a database to store it in. In this section, I will show you how to create a new database in MongoDB using MongoDB Compass.

1. Open MongoDB Compass and click the Connect button in the top left corner of the screen.
2. In the New Connection window, enter the connection details for your MongoDB instance. This includes the hostname, port number, and authentication details if necessary.
3. Click Connect to establish a connection to your MongoDB instance.
4. In the left-hand navigation pane, click Databases to view a list of existing databases.
5. Click the Create Database button in the top left corner of the Databases window.
6. Enter a name for your new database (e.g “mydatabase”) and click Create.

Congratulations, you have created a new database in MongoDB Compass! You can now begin creating collections and adding documents to your database.

How to Create a Collection in MongoDB

In MongoDB, a database collection is equivalent to a table in a relational database. A collection is a group of MongoDB documents that share a set of common characteristics.

In this section, I will show you how to create a new collection in MongoDB using Rust.

Create a new Rust function.

Open the src/main.rs file in your project directory and create a new function called create_collection. This function will create a new collection in your MongoDB database. Add the following code to your main.rs file:

async fn create_collection(client: &Client, db_name: &str, coll_name: &str) {
    let db = client.database(db_name);
    db.create_collection(coll_name, None).await.unwrap();
}

This function takes a Client object, a database name, and a collection name as arguments. Then it creates a new collection in the specified database.

Call the create_collection function.

In your main function, add the following code to call the create_collection function and create a new collection in your MongoDB database:

let client_options = ClientOptions::parse("mongodb://localhost:27017").await.unwrap();
let client = Client::with_options(client_options).unwrap();

let db_name = "mydatabase";
let coll_name = "mycollection";

create_collection(&client, db_name, coll_name).await;

This code will create a new Client object and call the create_collection function to create a new collection called “mycollection” in the mydatabase database.

Congratulations, you have now created a new collection in your MongoDB database using Rust.

In the next four sections, we will cover how to perform CRUD operations on your data, starting with inserting a document.

How to Insert a Document into a Collection in MongoDB

In MongoDB, a row is equivalent to a document in a collection. In this section, I will show you how to insert a new document into a collection in MongoDB using Rust.

Create a new Rust function.

Open the src/main.rs file in your project directory and create a new function called insert_document. This function will insert a new document into the specified collection in your MongoDB database. Add the following code to your main.rs file:

async fn insert_document(client: &Client, db_name: &str, coll_name: &str) {
    let db = client.database(db_name);
    let coll = db.collection(coll_name);

    let doc = doc! { "name": "John", "age": 30 };

    coll.insert_one(doc, None).await.unwrap();
}

This function takes a Client object, a database name, and a collection name as arguments. It then creates a new Collection object for the specified collection and inserts a new document into it.

Call the insert_document function.

In your main function, add the following code to call the insert_document function and insert a new document into your MongoDB collection:

let client_options = ClientOptions::parse("mongodb://localhost:27017").await.unwrap();
let client = Client::with_options(client_options).unwrap();

let db_name = "mydatabase";
let coll_name = "mycollection";

insert_document(&client, db_name, coll_name).await;

This code will create a new Client object and call its insert_one method to insert a new document with the fields name and age into the collection.

Congratulations, you have now inserted a new document into your MongoDB collection using Rust.

In the next section, I will cover how to retrieve a document from the collection and perform other CRUD operations on your data.

How to Retrieve a Document from a Collection in MongoDB

In MongoDB, you can retrieve a document from a collection by querying the collection with specific filter criteria.

In this section, I will show you how to retrieve a document from a collection in MongoDB using Rust.

Create a new Rust function.

Open the src/main.rs file in your project directory and create a new function called get_document. This function will retrieve a document from the specified collection in your MongoDB database. Add the following code to your main.rs file:

fn get_document(client: &Client, db_name: &str, coll_name: &str) {
    let db = client.database(db_name);
    let coll = db.collection(coll_name);

    let filter = doc! {"name": "John"};

    let result = coll.find_one(Some(filter), None).await.unwrap();
    match result {
        Some(doc) => println!("{}", doc),
        None => println!("No document found"),
    }
}

This function takes a Client object, a database name, and a collection name as arguments. It then creates a new Collection object for the specified collection and retrieves a document from it that matches the specified filter criteria.

In this example, we are retrieving a document in the collection that has a field called “name” with the value “John”.

Call the get_document function.

In your main function, add the following code to call the get_document function and retrieve a document from your MongoDB collection:

let client_options = ClientOptions::parse("mongodb://localhost:27017").await.unwrap();
let client = Client::with_options(client_options).unwrap();

let db_name = "mydatabase";
let coll_name = "mycollection";

get_document(&client, db_name, coll_name).await;

This code will create a new Client object, and retrieve a document from the mycollection collection that matches the filter criteria.

Congratulations, you have now retrieved a document from your MongoDB collection using Rust. In the next section, we will cover how to delete data from the collection.

How to Delete a Document from a Collection in MongoDB

In MongoDB, you can delete a document from a collection by specifying one or more criteria to match the document.

In this section, I will show you how to delete a document from a collection in MongoDB using Rust.

Create a new Rust function.

Open the src/main.rs file in your project directory and create a new function called delete_document. This function will delete a document from the specified collection in your MongoDB database. Add the following code to your main.rs file:

fn delete_document(client: &Client, db_name: &str, coll_name: &str) {
    let db = client.database(db_name);
    let coll = db.collection(coll_name);

    let filter = doc! {"name": "John"};
    coll.delete_one(filter, None).await.unwrap();
}

This function takes a Client object, a database name, and a collection name as arguments. It then creates a new Collection object for the specified collection and deletes a document from it that matches the specified filter criteria.

In this example, we are deleting a document from the collection that has a field called “name” with the value “John”.

Call the delete_document function.

In your main function, add the following code to call the delete_document function and delete a document from your MongoDB collection:

let client_options = ClientOptions::parse("mongodb://localhost:27017").await.unwrap();
let client = Client::with_options(client_options).unwrap();

let db_name = "mydatabase";
let coll_name = "mycollection";

delete_document(&client, db_name, coll_name).await;

This code will create a new Client object, and delete a document from the mycollection collection that matches the filter criteria.

Congratulations, you have now deleted a document from your MongoDB collection using Rust.

In the next section, I will cover how to modify documents in your collection.

How to Modify a Document in a Collection in MongoDB

In MongoDB, you can modify a document in a collection by updating one or more fields in the document. In this section, I will show you how to modify a document in a collection in MongoDB using Rust.

Create a new Rust function.

Open the src/main.rs file in your project directory and create a new function called update_document. This function will update a document in the specified collection in your MongoDB database. Add the following code to your main.rs file:

fn update_document(client: &Client, db_name: &str, coll_name: &str) {
    let db = client.database(db_name);
    let coll = db.collection(coll_name);

    let filter = doc! {"name": "John"};
    let update = doc! {"$set": {"age": 35}};
    coll.update_one(filter, update, None).await.unwrap();
}

This function takes a Client object, a database name, and a collection name as arguments. It then creates a new Collection object for the specified collection and updates a document in it that matches the specified filter criteria.

In this example, we are updating a document in the collection that has a field called “name” with the value “John”. We are setting the value of the “age” field to “35”.

Call the update_document function.

In your main function, add the following code to call the update_document function and update a document in your MongoDB collection:

let client_options = ClientOptions::parse("mongodb://localhost:27017").await.unwrap();
let client = Client::with_options(client_options).unwrap();

let db_name = "mydatabase";
let coll_name = "mycollection";

update_document(&client, db_name, coll_name).await;

This code will create a new Client object, and update a document in the mycollection collection that matches the filter criteria.

Congratulations, you have now updated a document in your MongoDB collection using Rust. Now, you have performed all basic CRUD operations on a MongoDB database.

Conclusion

In this article, I have introduced you to MongoDB and how to use it with Rust. I have covered the basics of setting up a MongoDB server, creating a database, and creating a collection within the database. I have also shown you how to insert, retrieve, modify, and delete data from your MongoDB database using Rust.

By leveraging the Rust programming language and the MongoDB database, you can build robust and scalable applications that can handle large amounts of data. Rust's performance and safety features make it an excellent choice for working with databases like MongoDB.

I hope that this article has provided you with a solid foundation for working with MongoDB in Rust. With the knowledge gained in this article, you should be able to build a wide range of applications that require a database backend.

Thank you for reading, and happy coding!

We will cover topics such as the syntax for defining and using modifiers, the _; symbol, using multiple modifiers on a single function, modifiers with arguments, enum-based modifiers, inherited and overridden modifiers, and examples of how to use modifiers in real-world contracts.

By the end of this article, you will have a deep understanding of how modifiers work and how to use them effectively in your Solidity code.

What are Solidity Modifiers?

A modifier is a special type of function that you use to modify the behavior of other functions. Modifiers allow you to add extra conditions or functionality to a function without having to rewrite the entire function.

To define a modifier, you use the modifier keyword followed by the name of the modifier and any parameters it may have.

Here is an example for a modifier:

modifier onlyOwner {
    require(msg.sender == owner);
    _;
}

In this example, the onlyOwner modifier has no parameters and includes a require statement that checks that the message sender is the contract owner.

If the message sender is the contract owner, the function will be executed. If the message sender is not the contract owner, the function will not execute.

To use a modifier, attach it to a function by placing it in the function definition. For example:

function changeOwner(address newOwner) onlyOwner public {
    // function body
}

In this example, the changeOwner function has the onlyOwner modifier attached to it. This means that in order to execute the changeOwner function, the caller must be the contract owner.

If the message sender is not the contract owner, the require statement in the onlyOwner modifier will fail and the function will not execute.

How Does the _; Symbol Work?

The _; symbol is a special symbol that is used in Solidity modifiers to indicate the end of the modifier and the beginning of the function that the modifier is modifying.

The body of a modifier is made up of one or more statements that are used to modify the behavior of the function, and the _; symbol.

Here is the onlyOwner modifier with the _; symbol:

modifier onlyOwner {
    require(msg.sender == owner);
    _;
}

Without the _; symbol, the compiler would not know where to insert the code from the modifier into the function.

How to Use Multiple Modifiers on a Function

You may want to use multiple modifiers on a single function. Solidity lets you use more than one modifier on a function as in the example below:

contract MyContract{
   address owner;

   modifier ownerChanges {
       _;
       require(msg.sender == owner);
   }

   modifier onlyOwner {
       require(msg.sender == owner);
       _;
   }

   function changeOwner(address newOwner) onlyOwner ownerChanges public {
       owner = newOwner;
   }
}

The order you place your modifiers in doesn’t matter. When you call the changeOwner function, the virtual machine executes both onlyOwner and ownerChanges.

How to Use Modifiers with Arguments

Modifiers in Solidity can have arguments of any data type supported by Solidity. Modifiers with arguments are defined in the same way as regular modifiers, with the addition of one or more parameters in the function definition.

Here is an example syntax for a modifier with regular arguments:

modifier onlyAllowedUser(address user) {
    require(msg.sender == user);
    _;
}

In this example, the onlyAllowedUser modifier has one parameter, user, which is of type address. The modifier includes a require statement that checks the value of the user parameter and only allows the function to execute if the message sender is equal to user.

To use a modifier with regular arguments, you can attach it to a function and pass the appropriate values as arguments. For example:

function updateData(uint id, bytes32 newData, address user) onlyAllowedUser(user) public {
    // function body
}

In this example, the updateData function has the onlyAllowedUser modifier attached to it and takes an address parameter called user. When the updateData function is called, the value of the user parameter is passed to the onlyAllowedUser modifier.

How to Create an Enum-based Modifier

Another way to use modifiers is to create an enum-based modifier. Enum-based modifiers allow you to specify a set of predefined values that can be used to determine whether or not a function should execute.

To create an enum-based modifier, you first need to define an enum type. An enum type is a special data type that consists of a set of named values called "members". Here is an example enum type:

enum ActionType {
    CREATE,
    UPDATE,
    DELETE
}

Once you have defined the enum type, you can create an enum-based modifier by adding a parameter of the enum type to your modifier function.

The modifier function should include a required statement that checks the value of the enum parameter and determines whether or not the function should execute. Here is an example of an enum-based modifier:

modifier onlyAllowedAction(ActionType action) {
    require(action == ActionType.CREATE || action == ActionType.UPDATE);
    _;
}

The modifier, called onlyAllowedAction, will only allow the function to which it is attached to execute if the value of the action parameter is either ActionType.CREATE or ActionType.UPDATE. If the value of action is anything else, the require statement will fail and the function will not execute.

To use the enum-based modifier, you would attach it to a function and pass the appropriate enum value as an argument. For example:

function updateData(uint id, bytes32 newData, ActionType action) onlyAllowedAction(action) public {
    // function body
}

In this example, the updateData function can only be executed if the action parameter is set to either ActionType.CREATE or ActionType.UPDATE.

How to Inherit and Override Modifiers

In Solidity, it is possible to inherit and override modifiers in order to reuse code and customize the behavior of functions.

To inherit a modifier, use the is keyword in the contract that you want to inherit the modifier from. For example:

contract BaseContract {
    modifier onlyOwner {
        require(msg.sender == owner);
        _;
    }
}

contract MyContract is BaseContract {
    // functions in MyContract can use the onlyOwner modifier
}

In this example, the MyContract contract inherits the onlyOwner modifier from the BaseContract. This means that any function in MyContract can use the onlyOwner modifier. The onlyOwner modifier ensures that only the contract owner can execute the function that it is attached to.

You can also override a modifier by defining a new version of the modifier in a contract that inherits from another contract. To do this, you can use the same name for the modifier and define a new implementation for it. For example:

contract BaseContract {
    modifier onlyOwner {
        require(msg.sender == owner);
        _;
    }
}

contract MyContract is BaseContract {
    // override the onlyOwner modifier
    modifier onlyOwner {
        require(msg.sender == newOwner);
        _;
    }
}

In this example, the MyContract contract overrides the onlyOwner modifier from the BaseContract. This means that any function in MyContract that uses the onlyOwner modifier will now check that the message sender is equal to the newOwner variable, rather than the owner variable.

Inheriting and overriding modifiers can be a useful way to reuse code and customize the behavior of functions in your Solidity contracts.

Conclusion

Modifiers in Solidity are special functions that modify the behavior of other functions. They allow developers to add extra conditions or functionality without having to rewrite the entire function.

Modifiers can have arguments and can be inherited and overridden to customize their behavior, and they can be used in combination with other modifiers to further customize the behavior of functions.

Enum-based modifiers allow developers to specify a set of predefined values to determine whether or not a function should execute. State-based modifiers use the contract's current state to determine whether or not a function should execute.

Modifiers can help developers write cleaner, more modular code and make it easier to maintain and update their contracts.

Thanks for reading!

During the process, the program learns from data by discovering patterns. This reduces the need for programmers to hard code rules in some applications.

Languages like Python and R are excellent for learning and carrying out machine learning tasks. But those languages aren’t absolute. They have weaknesses. Some machine learning applications may need to perform operations with great speed and computer resource efficiency.

Rust is a powerful and efficient programming language. Although Rust doesn’t have a mature ecosystem, the programming language’s nature makes it perfect for applications that require speed and efficiency.

Rust programmers will find this tutorial useful in getting started with machine learning. And, machine learning engineers will find this tutorial useful in getting started with machine learning on Rust.

Prerequisites

To follow along with this tutorial you’ll need the following:

• Knowledge of Rust
• Rust installed in your system

What is Machine Learning?

In machine learning, a model is a software object that can understand patterns from data. Training a model is the process of giving data to the model to draw out patterns. Machine learning is the process of training a model to carry out tasks.

Once you've trained your model, you can use it to draw conclusions from new data. You can either base those conclusions on classifications or predictions. A predictive model uses current data to predict an event, result, or outcome. A classification model uses data to classify an object, or concept.

The following diagram is a basic overview of the machine learning process:

What is a Decision Tree?

A decision tree algorithm is one of the most straightforward machine learning algorithms. This algorithm, unlike most other algorithms, gives a real sense of what machine learning is about.

A decision tree is a machine learning algorithm for classification and regression tasks. A decision tree is structured like a tree. It has a root node, internal nodes, leaf nodes, and branches.

The table below is an example of data that represents a classification of four animals with their properties:

A model recognizes the pattern(s) in the table, then creates a tree with this structure:

The root node is the first node in a decision tree. The leaf nodes are on the final line of the decision tree. The inner nodes are located between the root nodes and the leaf nodes. A decision tree can have more than one layer of inner nodes.

We'll use this algorithm in this article.

Getting Started

There are a bunch of tools that allow you to create machine learning applications in Rust. All the tools are great, but for this tutorial you’ll use Linfa. Linfa is a toolkit that is similar to the popular Python machine learning toolkit scikit-learn.

In this section, you’ll learn how to set up a Rust project for machine learning. The process of setting up a project is relatively simple. All you need to do is follow these steps:

First, create a new project called ml-project with the following command:

cargo new --bin ml-project

Next, paste the following dependencies in ml-project’s Cargo.toml file, under [dependencies]:

linfa = "0.6.0"
linfa-trees = "0.6.0"
linfa-datasets = { version = "0.6.0", features = ["iris"] }

Finally, run the following command to build the dependencies:

cargo build

The following is an explanation of the dependencies:

• linfa is the base package for Linfa machine learning models.
• linfa-trees is a sub-package for building decision tree models.
• linfa-datasets is a package that provides already prepared datasets.

The linfa-datasets package is optional. If you want to prepare your own dataset, follow the next section.

How to Prepare the Dataset

Most machine learning models used in day-to-day projects are trained with external data, not the data provided by the toolkit. In this section, you’ll learn how to prepare your own dataset from a csv file.

First, you need to get a dataset if you don’t have one you can use. You can get a dataset from Kaggle. For this tutorial, I’ll use the heart disease dataset. The heart disease dataset looks like the below:

In this dataset, target indicates that a person has heart disease. 1 means they have a heart disease, 0 means they do not have a heart disease.

The rest of the fields on the dataset are details of each person. A model can learn from this dataset and be able to tell if a person has a heart disease or not.

Once you have downloaded the dataset, extract the csv file into your project’s src folder.

.
├── Cargo.lock
├── Cargo.toml
└── src
    ├── heart.csv
    └── main.rs

To prepare a dataset, you’ll need to add the csv and ndarray packages to your project. Open Cargo.toml, and write the following under [dependencies]:

csv = "1.1"
ndarray = "0.15.6"

Now, run cargo build to download the packages, and you are ready to go.

In the coming steps, I’ll guide you through building a get_dataset function. The get_dataset function reads the heart.csv file, parses its content, prepares a dataset with its contents, and returns the prepared dataset. Let’s get started!

First, import the necessary packages:

use csv::Reader;
use std::fs::File;
use ndarray::{ Array, Array1, Array2 };
use linfa::Dataset;

Next, write the get_dataset function below into main.rs:

fn get_dataset() -> Dataset<f32, i32, ndarray::Dim<[usize; 1]>> {
 let mut reader = Reader::from_path("./src/heart.csv").unwrap();

 let headers = get_headers(&mut reader);
 let data = get_data(&mut reader);
 let target_index = headers.len() - 1;

 let features = headers[0..target_index].to_vec();
 let records = get_records(&data, target_index);
 let targets = get_targets(&data, target_index);

 return Dataset::new(records, targets)
   .with_feature_names(features);
}

Finally, finish up by adding the definitions for get_headers, get_data, get_records, and get_targets:

fn get_headers(reader: &mut Reader<File>) -> Vec<String> {
 return reader
   .headers().unwrap().iter()
   .map(|r| r.to_owned())
   .collect();
}

fn get_records(data: &Vec<Vec<f32>>, target_index: usize) -> Array2<f32> {
 let mut records: Vec<f32> = vec![];
 for record in data.iter() {
   records.extend_from_slice( &record[0..target_index] );
 }
 return Array::from( records ).into_shape((303, 13)).unwrap();
}

fn get_targets(data: &Vec<Vec<f32>>, target_index: usize) -> Array1<i32> {
 let targets = data
   .iter()
   .map(|record| record[target_index] as i32)
   .collect::<Vec<i32>>();
  return Array::from( targets );
}

fn get_data(reader: &mut Reader<File>) -> Vec<Vec<f32>> {
 return reader
   .records()
   .map(|r|
     r
       .unwrap().iter()
       .map(|field| field.parse::<f32>().unwrap())
       .collect::<Vec<f32>>()
   )
   .collect::<Vec<Vec<f32>>>();
}

Here’s a step-by-step explanation of the get_dataset function:

First, initialize a reader pointing to ./src/heart.csv:

let mut reader = Reader::from_path("./src/heart.csv").unwrap();

Next, extract the headers and data from reader:

let headers = get_headers(&mut reader);
let data = get_data(&mut reader);

Then, calculate the index of target in the headers:

let target_index = headers.len() - 1;

After that, get the features from headers:

let features = headers[0..target_index].to_vec();

Next, retrieve the records and targets from data:

let records = get_records(&data, target_index);
let targets = get_targets(&data, target_index);

Finally, build the dataset with records, targets, and features, then return:

return Dataset::new(records, targets)
   .with_feature_names(features);

To finish up the function and to see how the dataset looks, make the following your main function:

fn main() {
   let dataset = get_dataset();
   println!("{:?}", dataset);
}

Once you make that your main function and run it with cargo run, you’ll see the dataset in the output:

DatasetBase { records: [[63.0, 1.0, 3.0, 145.0, 233.0, ..., 0.0, 2.3, 0.0, 0.0, 1.0],
 [37.0, 1.0, 2.0, 130.0, 250.0, ..., 0.0, 3.5, 0.0, 0.0, 2.0],
 [41.0, 0.0, 1.0, 130.0, 204.0, ..., 0.0, 1.4, 2.0, 0.0, 2.0],
 [56.0, 1.0, 1.0, 120.0, 236.0, ..., 0.0, 0.8, 2.0, 0.0, 2.0],
 [57.0, 0.0, 0.0, 120.0, 354.0, ..., 1.0, 0.6, 2.0, 0.0, 2.0],
 ...,
 [57.0, 0.0, 0.0, 140.0, 241.0, ..., 1.0, 0.2, 1.0, 0.0, 3.0],
 [45.0, 1.0, 3.0, 110.0, 264.0, ..., 0.0, 1.2, 1.0, 0.0, 3.0],
 [68.0, 1.0, 0.0, 144.0, 193.0, ..., 0.0, 3.4, 1.0, 2.0, 3.0],
 [57.0, 1.0, 0.0, 130.0, 131.0, ..., 1.0, 1.2, 1.0, 1.0, 3.0],
 [57.0, 0.0, 1.0, 130.0, 236.0, ..., 0.0, 0.0, 1.0, 1.0, 2.0]], shape=[303, 13], strides=[13, 1], layout=Cc (0x5), const ndim=2, targets: [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], shape=[303], strides=[1], layout=CFcf (0xf), const ndim=1, weights: [], shape=[0], strides=[0], layout=CFcf (0xf), const ndim=1, feature_names: ["age", "sex", "cp", "trestbps", "chol", "fbs", "restecg", "thalach", "exang", "oldpeak", "slope", "ca", "thal"] }

How to Create a Decision Tree Model

In this section, I’ll show you how to create a decision tree model and train it. The dataset I’ll use is the iris dataset provided by linfa-datasets.

The iris dataset contains a record of the sepal width, sepal height, petal width, and petal height of several irises, and classifies each record according to number-labeled species.

The code for the model is simple. Open the main.rs file, and paste the following into it:

use linfa_trees::DecisionTree;
use linfa::prelude::*;

fn main() {
    let (train, test) = linfa_datasets::iris()
        .split_with_ratio(0.9);

    let model = DecisionTree::params()
        .fit(&train).unwrap();

    let predictions = model.predict(&test);

    println!("{:?}", predictions);
    println!("{:?}", test.targets);
}

Here's an explanation:

First, import the necessary packages:

use linfa_trees::DecisionTree;
use linfa::prelude::*;

Next, fetch the dataset, and split into testing and training data:

let (train, test) = linfa_datasets::iris()
    .split_with_ratio(0.9);

After that, initialize the model and train it with the training data:

let model = DecisionTree::params()
    .fit(&train).unwrap();

Then, use the testing data to make some predictions:

let predictions = model.predict(&test);

Finally, compare the predictions with the actual values:

println!("{:?}", predictions);
println!("{:?}", test.targets);

If you run the program with cargo run, you’ll get the predicted category and the actual category in the terminal as output:

$ cargo run
[2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2], shape=[15], strides=[1], layout=CFcf (0xf), const ndim=1
[2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2], shape=[15], strides=[1], layout=CFcf (0xf), const ndim=1

From the above, you can see that this model is 100% accurate. This won’t always be the case for all machine learning models. If you shuffle the dataset before training the model in the above, the model may not be as accurate anymore.

The goal of machine learning is to be as accurate as possible. Most times 100% accuracy is not possible.

Conclusion

In this tutorial, you learnt a little about machine learning, and you also saw how to create a decision tree model using Rust.

Machine learning models in Linfa follow a similar process in building and training, so all you need to do to use other types of models is to learn about each one, and you are good to go.

You can learn more about Linfa and the models it supports using its documentation.

Thanks for reading, and happy coding!