Forem: Kelvin Kirima

The Mechanics of mutable and immutable references in Rust

Kelvin Kirima — Fri, 09 Feb 2024 21:42:00 +0000

The design choices of a programming language have direct implications on how we write code. One such design choice is the concept of ownership and borrowing in the Rust programming language.

Ownership, References and Immutability

Stated simply, the concept of ownership deems that we can only have one owner of a value at a time, this value can be passed around severally for read-only operations by immutably borrowing or referencing, but we can only have one mutable borrow at a time.

fn main() {
    let mut input = String::new();
    input.push_str("Hello World");
    println!("input value is: {:?}", input);

    let take_ownership = input;
    println!("Taken ownership of value {:?}", take_ownership);

    let _illegal = input; // throws an error -> use of moved value `input`
}

The error message tells us we are trying to use a value which has already been moved to another memory location. When we create the variable take_ownership, we move the value in the input's memory location to take_ownership, thus trying to allocate input's value to another variable fails, because the value is no longer there. This is all by design, imagine if we were successful in having two variables own the value at the same time, and then have both variables mutate the value, we got ourselves a race condition, not good. Innit?

There's a work-around to this that makes the error go away quickly; Instead of taking ownership, we just borrow the value

let borrow_value = &input;
println!("...");

let another_borrow = &input
println!("...");

The ampersand sign & denotes that we are taking a reference to the memory address the value is stored, but we're not taking ownership of the value itself. Now we can have as many borrows as we want, but there's a catch: We can only have one mutable reference at a time.

let borrow_value = &mut input; 
let another_borrow = &mut input;

If you tried writing code like the one above, your Rust LSP should already be telling you that what you're doing is unacceptable:

error[E0499]: cannot borrow input as mutable more than once

But it's possible to have another mutable borrow when the first borrow goes out of scope. The code below runs successfully because we create the variable another_borrow after borrow_value has already been used and it's scope ended.

let borrow_value = &mut input;
borrow_value.push_str(" Changers");

let another_borrow = &mut input;
println!("another_borrow: {:?}", another_borrow);

The reference's scope start from where it is introduced and continues through the last time that reference is used; when the reference goes out of scope, it's borrow ends, and the value becomes available for borrowing again. When all references to the value are gone, Rust frees the memory where the value is located. These rules of ownership, borrowing and scope are what enables Rust to be able to allocate and free memory safely without a garbage collector, how practical!

Dereferencing

We've established that references do not hold any values by themselves, instead they point to the location in memory where the actual value is stored. Now, what if we want to modify the actual value the reference is pointing at? Take this simple example:

let mut value = 20;
let ref_val = &mut value;

Imagine that we want to change the ref_value to 30; to a new Rustacean, the first thought would be to do something like this:

fn main() {
   let mut value = 20;
   let ref_val = &mut value;
   ref_val = 30;
}

Trying to write the above code will have the compiler sympathizing with us:

error[E0308]: mismatched types
  --> src/main.rs:20:17
   |
|     let ref_value = &mut value;
   |                     ---------- expected due to this value
|     ref_value = 30;
   |                 ^^ expected &mut {integer}, found integer
   |
help: consider dereferencing here to assign to the mutably borrowed value
   |
 |     *ref_value = 30;
   |     +

I encourage you to take a minute and read the error message keenly. We get the error because ref_value holds the reference to the value, and not the value itself; in other terms, we are trying to assign to the reference, and not the value it points to, and Rust does not allow us to assign directly to the reference because this would mutate the actual value. So, what do we do? The compiler has already helped us with that. To assign the integer to the actual value, we need to dereferenceref_value and access the actual value behind it; we do this using the unary operator*.

let mut value = 20;
let ref_val = &mut value;
*ref_val = 30;

One question you may already have is why we didn't have to do that with the push_str operations earlier:

let borrow_value = &mut input;
borrow_value.push_str(" Changers");

That's because when we use the dot operator, the expression on the left-hand side of the dot is auto-referenced/auto-derefenced automatically. You can read more about the dot-operator here.

A more Interesting Problem

This article was inspired by a problem I encountered while working with the sqlx library; I wanted to have a database connection that I can reuse across multiple queries. Sqlx has a begin method that creates a database connection and immediately begins a new transaction, so what I need to do is figure out how to compose multi-statement transactions with it. My first attempt looks like so:

async fn demo_txn(db: PgPool) -> Result<()> {
    let tx = db.begin().await.map_errr(|err| {
        error!("error starting database transaction: {err}");`
    })?;

    let row = sqlx::query("...").fetch_one(&mut tx).await?;

    sqlx::query("...").execute(&mut tx).await?;
}

Above, I create a transaction, and then try to consume a mutable reference to the transaction in my queries; however, the code throws this error:

error[E0277]: the trait bound &mut Transaction<'_, Postgres>: sqlx::Executor
<'_> is not satisfied
   --> src/routes/signup.rs:117:14
    |
 |     .execute(&mut tx)
    |      ------- ^^^^^^^ the trait sqlx::Executor<'_> is not implemented 
for &mut Transaction<'_, Postgres>
    |      |
    |      required by a bound introduced by this call
    |
    = help: the following other types implement trait sqlx::Executor<'c>:
              <&'c mut PgConnection as sqlx::Executor<'c>>
              <&'c mut PgListener as sqlx::Executor<'c>>
              <&'c mut AnyConnection as sqlx::Executor<'c>>
              <&Pool<DB> as sqlx::Executor<'p>>

The error tells us that the sqlx::Executor trait, which provides a database connection we can use for executing queries is not implemented for our mutable reference to the Transaction type. These are one of those errors that have you scratching your head because the compiler has no more help to offer you, we are basically on our own now. The logical thing to do here is to dig into other people's code and see if I can find out how others construct multi-statement transactions in sqlx. I came across a similar problem on Github, and the solution offered is to dereference the transaction:

async fn demo_txn(db: PgPool) -> Result<()> {
    let tx = db.begin().await.map_errr(|err| {
        error!("error starting database transaction: {err}");
    })?;

    let row = sqlx::query("...").fetch_one(&mut *tx).await?; // notice the *

    sqlx::query("...").execute(&mut *tx).await?; //notice *
}

And true enough, the errors go away; Interesting, let's dig a little deeper to understand what's going on. The begin method we call on the db looks like so:

pub async fn begin(&self) -> Result<Transaction<'static, DB>, Error>

When we call ? on the Result, we are left with the Transaction type:

pub struct Transaction<'c, DB>
where
    DB: Database,
{ ...}

So, when we do *tx, we are asking for a mutable dereference to the Transaction because our methods are in a mutable expression context. Rust requires that types that want to be dereferenced implement the Deref trait - for immutable dereference, or the DerefMut trait for mutable dereferences. The transaction type implements both of these traits, here's the DerefMut implementation:

impl<'c, DB> DerefMut for Transaction<'c, DB>
where
    DB: Database,
{
    #[inline]
    fn deref_mut(&mut self) -> &mut Self::Target {
        &mut self.connection
    }
}

The * uses the above DerefMut implementation and yields a mutable <DB as Database>::Connection (the associated connection type for whichever DB we're using). I'm using Postgres, so the deref gets us a mutable PgConnection which implements the sqlx::Executor trait that was missing and thus causing the compilation error.

I understand this has been a long exposition, but an example like this goes to show how some of the errors we may encounter even with trait bound issues are directly tied to the concepts of ownership and references - and how deep they can go.

Finishing Up

Thanks for reading! I hope this article has helped shine some light on arguably some of the most important Rust concepts.

This post was first published at https://kelvinkirima.com/

Generating the nth Fibonacci in Rust.

Kelvin Kirima — Wed, 14 Jul 2021 22:05:49 +0000

What’s a Fibonacci sequence?

Fibonacci numbers are numbers that form a sequence, called the Fibonacci sequence, such that each number is the sum of the two preceding ones, starting from 0 and 1.

The Fibonacci sequence

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144

Written as an expression,

Fn = Fn-1 + Fn-2

Getting Started.

You need to have Rust installed on your computer, for Linux or macOS run the following command in your terminal,



$ curl --proto '=https' --tlsv1.2 https://sh.rustup.rs -sSf | sh

If the install is successful, the following line will appear:

Rust is installed now. Great!

For those on windows, see the Rust docs.
Now run this command to create a new Rust project.



cargo new rust_fibonacci

Then



cd rust_fibonacci

Open the directory in your IDE
You’ll find that Rust generates a main.rs file for you, this is our entry point to Rust, open the file. It looks like this:



fn main () {
    println!(“Hello world”);
}

Now let’s go ahead and edit the code..

Fibonacci Function

Let’s create a function below the main function that generates a fibonacci sequence



fn fib (n: i32) -> i32 {
    if n <= 0 {
          return 0;
    } else if n== 1{
          return 1;
} else {
    return fib (n-1)  + fib(n-2);
 }
}

Here is what’s happening. First, we create a function (fn) named fib and pass variable n as a parameter. In Rust, we have to specify the type of the parameter and its return value. I specify it’s a u32, meaning it can only accept unsigned/positive integers of 32 bits and the -> is specifying the return type of the function which is also a u32 integer.
Next, I use an if expression followed by a condition that checks if the value of n is less or equal to 0 and returns 0 if that’s the case. We then check to see if the value of n is 1 and return 1. In the else part, we implement the logic of the Fibonacci sequence by recursively calling the function with a different integer.

Printing the Values on the screen.

Now let’s go back to our main function and modify it to look like this...



fn main( ){
    for int in 0..15 {
         println! ( “fibonacci ({}) => {}”, int, fib(int));
     }
}

Inside the main function is a for loop that loops over every integer from 0 to 15 and we use the println! to print each integer we pass and its corresponding Fibonacci value.
Type cargo run in your terminal and the output should look like this...

Accept User Input.

We want our program to allow the user to input a number and gets its corresponding Fibonacci. Edit the main function to look like so,



use std::io;
fn main ( ) {
    println! (“To quit the program type `exit` “);
    loop {
         println! (“TYPE A POSITIVE NUMBER”)
         let mut int = String::new;
         io::stdin( )
    .read_line(& mut int)
    .expect (“Failed to read your input”);
    if int.trim( ) == “exit” {
        break;
        }
        let int: u32 = match int.trim()
         .parse() {
          Ok(int) => int,
          Err(_) => continue,
          };
        println!("Fibonacci ({}) => {}", int, 
        fib(int));    
}

Let’s go over the above code line by line.
First, we import a library that allows us to handle user input.
use std::io;
Rust brings only a few types into the scope of every program in the prelude. If a type you want to use isn’t in the prelude, bring that type into scope explicitly with a use statement.
Inside the main function, we first let the user know how to quit the program by using the println! Macro to print a string to the screen.

Inside the Loop.

Next, we create a loop using the loop keyword that will keep running until you break out by typing exit(we’ll see how that happens in a moment). We then let the user know how to interact with the game each loop by using println! again to print a string on the screen.



         println! (“TYPE A POSITIVE NUMBER”);

variables and mutability

Each time through the loop, we create a mutable variable called int



let mut int = String::new;

Variables in Rust are immutable by default so we have to add the mut keyword when we are creating a mutable variable.
On the other side of the equal sign (=) is the value that int is bound to, which is the result of calling String::new, a function that returns a new instance of a String. So, what we are doing is creating a mutable variable that is currently bound to a new, empty instance of a String.
We then use the std::io library that we imported by calling the stdin function from the iomodule…



  io::stdin( )
     .read_line( &mut int)

The next line, .read_line(&mut int), calls the read_line method on the standard input handle to get input from the user.read_line takes whatever the user types into standard input and append that into a string. We’re also passing one argument ( &mut int)to the method. The & indicates that the argument is a reference, references are also immutable by default so you need to write &mut int to make it mutable.

The next part is this method:



.expect("Failed to read line");

Is a Result type that represents either success (Ok) or failure (Err). AS I mentioned,read_line puts what the user types into the string we’re passing it, but it also returns a value — in this case, an io::Result. The Result types are enumerations/enums. An enumeration is a type that can have a fixed set of values, and those values are called the enum’s variants.

If this instance of io::Result is an Err value, expect will cause the program to crash and display the message that you passed as an argument to expect. If this instance of io::Result is an Ok value, expect will take the return value that Ok is holding and return just that value to you so you can use it.

Our next piece of code is:



if int.trim( ) == “exit” {
        break;
            }

That checks to see if a user types exit to break out of the program. The .trim( ) method is passed to eliminate any whitespace at the beginning and the end.
In the next block of code,



let int: i32 = match int.trim( )
        .parse ( ){ 
        Ok (int)=> int,
        Err( _ )  => continue,
     }

We create a variable named int, Rust allows us to shadow the previous value of int with a new one. We often use this feature in situations in which we want to convert a value from one type to another type.
We bind int to the expression int.trim().parse(). The int in the expression refers to the original int that was a String with the input in it. The .trim() method on a String instance will eliminate any whitespace at the beginning and end. We use the .parse() method to turn the string into an integer. parse returns a Result type and Result is an enum that has the variants Ok or Err, remember? We use a match expression to decide what to do next based on which variant of Result that was returned. If the user typed in a number, we get Ok and store the number in int. If not, we call continue and instruct the user to pass in a positive integer again. The program basically ignores all errors that parse might encounter!
We finally print each integer the user passes and its corresponding Fibonacci value.



println!(“fibonacci({ }) => { }”, int, fib(int));

The entire code should now look like this,



use std::io;

fn main () {

   println!("To end the program, type exit ");

   loop {

       println!("Type a positive integer");

       let mut int = String::new();

        io::stdin()

       .read_line(&mut int)

       .expect("");

       if int.trim() == "exit"{

           break;

       }

       let int: u32= match int.trim()

       .parse() {

           Ok(int) => int,

           Err(_) => continue,

       };

       println!("Fibonacci ({}) => {}", int, fib(int));

}

}

fn fib (n: u32) -> u32 {

   if n <= 0 {

       return 0;

   } else if n == 1 {

       return 1;

   }   fib(n - 1) + fib(n - 2)

}

Conclusion

This was a great exploration of several Rust concepts like variables, loops, match, conditionals and data types. You could also go through the guessing game in the Rust book which I borrowed most concepts of this program from. Am looking forward to tackling more challenges and building better programs.

This blog was first published in my blog

What Is The Javascript Event Loop?

Kelvin Kirima — Sun, 21 Feb 2021 18:21:51 +0000

Javascript is single-threaded,i.e, it executes only one operation at a time. This process of executing only one operation at a time on a single thread is the reason we say javascript is synchronous. But then what happens if a task takes too long to complete? Will all the other tasks be halted as we wait for this particular task to complete? This could clearly slow down our applications. To avoid such implications, javascript has a concurrency model based on the event loop that provides it with the ability to process multiple tasks asynchronously.
This article will help you understand why javascript is single-threaded and yet asynchronous by learning about the javascript runtime environment, the event loop and the mechanisms behind it.

Javascript Runtime

Each browser has a Javascript runtime environment.
Here is an illustration to help us visualize the runtime.

So, the javascript runtime consists of

Javascript Engine

Each browser uses its different version of the javascript engine. Some of the popular ones are V8(Chrome), Quantum(Firefox) and Webkit(Safari). Inside the engine, we have a memory heap and a call stack.

Memory heap

Memory is allocated every time we create objects, declare functions or assign variables. This memory is stored in the heap.

Call Stack

The single-threaded nature of javascript is because it has only one call stack. Within the call stack, your javascript code is read and executed line by line. The call stack follows the First In Last Out (FILO) principle, the function that is first added is executed last. once a function gets executed it's then get popped off the stack. Let's look at some code to clear the concept.

const getMovie = () =>{
 console.log ('Avengers')
}
getMovie()
// Avengers

Here is how the JS engine handles this code...

first, it parses the code to check for syntax errors and once it finds none, it goes on to execute the code.
it sees the getMovie() call and it pushes it to the stack.
getMovie() calls console.log() which then gets pushed to the top of the stack...
JS engine executes that function and returns Avengers to the console. The log is then popped off the stack.
The javascript engine then moves back to the getMovie() function, gets to its closing brackets and pops it off the stack(as it's done executing). As illustrated, the functions are added to the stack, executed and later deleted. Note that the function at the top of the stack is the one on focus and the JS engine only moves to the next frame(each entry in the call stack is called a stack frame) when the one above is returned and popped off the stack. This process of the call stack returning the frame at the top first before moving on to the next is why we say the JS engine runs synchronously.

Now suppose you want to fetch some data from an external file or you want to call an API that takes a while before it returns, You want the users to be able to continue using the program while waiting for the response, you cannot afford for your code to stop executing, javascript has a way to make this possible and here is where we introduce the Web APIs.

Web APIs

The Web APIs are provided by the browser, they live inside the browser's javascript runtime environment but outside the javascript engine. HTTP, AJAX, Geolocation, DOM events and setTimeout are all examples of the web APIs. Let's use a code example to help us figure out how web APIs help us in writing asynchronous code.

console.log ('1') // outputs 1 in the console
const getNumber = () =>{
//in this setTimeout, we set the timer to 1s (1000ms = 1s)
//and pass a callback that returns after 1s
setTimeout((cb)=>{
console.log('2')
}, 1000)
}
getNumber()
console.log('3')
//1
//3
//2

Let's evaluate how javascript runs this code and its output

as usual, first, it parses the code looking for syntax errors and on finding none, it continues to execute the code.
the first console.log is pushed to the stack, 1 is returned and its popped off the stack.
the next function, getNumber(), is pushed to the stack
getNumber() calls the setTimeout which is part of the web APIs, remember?
When the setTimeout is called to the stack, the callback with the timer is added to the appropriate web API where the countdown starts. The setTimeout is popped out of the stack.
getNumber() is done returning and consequently removed from the stack.
the last console.log is added to the stack, returns 3 to the console, and removed from the stack.

So, what happens after 1s and the timer countdown is finished? You would think that the callback is popped back from the web API to the call stack, but if it did this, the callback would randomly appear in the middle of some other code being executed, to prevent such a scenario, web API adds the callback to the message queue instead.

The message queue is basically a data structure that javascript runtime uses to list messages that need to be processed. Unlike the call stack, the message queue uses the First In First Out(FIFO) principle, The first function added to the queue is processed first.

Now, how does javascript runtime know that the stack is empty? or how do events get pushed from the message queue to the call stack? enter the event loop.
The job of the event loop is to constantly monitor the call stack and the message queue. If the call stack is empty, it takes the first event on the message queue and pushes it to the call stack. Both the call stack and the message queue may be empty for some time, but the event loop never stops checking.

Back to our code, the event loop checks and sees that the call stack is empty, so it pushes our callback (cb) to the stack where it returns 2 to the console and is then removed from the stack. Our code is done executing.

In addition

What would happen if we passed 0 milliseconds to setTimeout?

const getCurrency = ()=>{
 setTimeout(()=>{
 console.log('dollar')
}, 0)
}
getCurrency()
const name = () =>{
console.log('Frank')
}
name()
// Frank
// dollar

If you copy the above code and view it in the console, you shall notice that Frank is printed first and then dollar. Here is how JS handles this code:

first, it parses the code looking for syntax errors before going on to execute it.
getCurrency() is pushed to the stack.
getCurrency() calls setTimeout, JS engine sees its a web API and thus adds it to the web APIs and setTimeout is popped off the stack. getCurrency() is also removed from the stack.
Since the timer is set to 0s, web API immediately pushes the callback to the message queue, consequently, the event loop checks to see if the stack is empty, but it's not because
as soon as setTimeout was removed from the stack, name() got pushed to the stack immediately.
name() calls console.log which returns Frank and pops off the stack.
name() is done returning and is removed from the stack too.
The event loop notices that the call stack is now empty and pushes the callback from the message queue to the call stack.
The callback calls console.log, which returns dollar and pops off the stack. The callback is done executing and is removed from the stack. Our code is finally done executing.

This code shows us that calling the setTimeout with a delay of 0 milliseconds doesn't execute the callback after the specified interval, the delay is the minimum time required by the runtime to execute the callback and not a guaranteed time.
The callback has to wait for other queued messages to complete and the stack to clear before it's pushed to the stack and returned.

Conclusion

Knowledge of the javascript runtime helps you understand how javascript runs under the hood and how different pieces fit together to make javascript the great language as we know it. I hope this article gave you a solid grasp of this fundamental concept. See yah!

How Memory Is Allocated In JavaScript.

Kelvin Kirima — Thu, 28 Jan 2021 08:09:04 +0000

When writing javascript code, you usually don't have to worry about memory management. This is because javascript automatically allocates the memory when we create variables, objects and functions and releases the memory when they are not being used any more(the release of memory is known as garbage collection). Knowing how the memory is allocated is therefore not always necessary but it will help you gain more understanding of how javascript works and that is what you want, right?

Memory life cycle

The memory life cycle is comprised of three steps, common across most programming languages. These steps are memory allocation, memory use and memory release.

memory allocation

When you assign a variable, create an object or declare a function, some amount of memory has to be allocated.

// allocating memory via a variable
const assignMemory = 'memory is assigned'

// allocating memory for an object and its values
const myObject = {
 name:'Kevin'
 title:'Frontend developer'
}

//memory allocation for functions
const getSum = (a,b) => a + b
}

memory use

Memory is used every time we work with data in our code, either read or write. When we change the value of an object or pass an argument to a function, we are basically using memory, cool!

memory release

When we no longer use the variables and objects, javascript automatically relieves this memory for us. It is, however, difficult to determine when the allocated memory is no longer needed. Javascript uses some form of memory management known as garbage collection to monitor memory allocation and determine when allocated memory is no longer needed and release it. There is no method which can predict with complete accuracy which values are ready for release and as such the garbage collection process is mostly an approximation.

Garbage Collection

Since it's not possible to entirely decide which memory is needed or not, garbage collectors use two algorithms to evaluate which objects can be removed from memory. Let's look at these algorithms and their limitations.

Reference

In the reference counting algorithm, an object is evaluated as garbage if no other part of the code reference to it. Let's look at this code in order to get this concept clearly.

//create an object in the global scope
const toWatch = { showName:'Big Bang Theory'}
//javascript allocates memory for the showName object
// the toWatch variable becomes reference for this object
//this existing reference prevents showName from being
//being removed by the garbage collector

The only existing reference to the showName object above is the toWatch variable. If you remove this variable, the garbage collector will know the object it pointed to is no longer needed and it will release it from the memory.

const toWatch = null
//garbage collector will detect that
//the showName object is no longer reachable and
//not needed and it will release it from memory

The major drawback of this algorithm is that it does not pick up on circular reference. If two variables reference each other but are not needed on any other part of the code, the garbage collector will not remove them from memory as they are referenced and thus 'needed' as per the standards of this method.

//create a function that has a circular reference
function circularRef(){
 const foo = {}
 const bar = {}
 foo.a = bar
 bar.a = foo
}
circularRef()
//though variables foo and bar don't exist outside
//this function, garbage collector will not count 
//them as ready for collection because they
//reference each other

Mark and Sweep algorithm

This algorithm views an object as ready for collection if it is not connected to the root. In javascript, the root is the global object. The garbage collector visits all objects connected to the root(global object) and marks them as reachable or live. It then marks all objects that are connected to the root. This approach solves the circular reference problem because all elements not connected to the global object will not be marked as live, regardless of if it's referenced by other non-live elements.
Those elements that are not marked are considered unreachable and safe for collection.

Conclusion

Memory allocation and garbage collection works automatically, as developers we do not have to trigger it or prevent it but I hope this article gave you a good grasp of the process and what happens on the background.

p.s feel free to ask me any question regarding this(or anything javascript) or add a comment. Thanks, ciao!