Coder Legion - Recent posts tagged rust-lang

New Rust Tutorial: Structured Logging with tracing

Fri, 21 Nov 2025 11:32:59 +0000

For this week’s Rust update, I released a new episode of Fearless in Rust focusing on production-ready logging with tracing.

This video shows how to:

set up flexible log layers
output compact or JSON logs
attach fields like source_id for request tracing
use TraceLayer to auto-log HTTP traffic
apply #[instrument] to clean up debugging

▶️ https://youtu.be/UBxHiPFMg0M

Great for anyone building API services or distributed systems in Rust.

Runtime-initialized variables in Rust

Thu, 05 Jun 2025 07:03:35 +0000

Rust offers different ways to initialize compile time-initialized variables. Recently, I had to create a runtime-initialized variable: existing approaches don't work in this case. I want to describe multiple ways to achieve it in this post.

Constants

The Rust language allows you to create constants. Two keywords are available: const and static.

>Sometimes a certain value is used many times throughout a program, and it can become inconvenient to copy it over and over. What’s more, it’s not always possible or desirable to make it a variable that gets carried around to each function that needs it. In these cases, the const keyword provides a convenient alternative to code duplication:

>`rust
>const THING: u32 = 0xABAD1DEA;

>let foo = 123 + THING;
>`

>-- Keyword const

>A static item is a value which is valid for the entire duration of your program (a 'static lifetime).

>On the surface, static items seem very similar to const: both contain a value, both require type annotations and both can only be initialized with constant functions and values. However, static are notably different in that they represent a location in memory. That means that you can have references to static items and potentially even modify them, making them essentially global variables.

>Static items do not call drop at the end of the program.

>There are two types of static items: those declared in association with the mut keyword and those without.

>-- Keyword static

None of the above work with struct.

I stand corrected: https://www.reddit.com/r/rust/comments/1l0uwzy/comment/mvgghb0/.

const REGEXP_WAREHOUSE_ENDPOINT: Regex = Regex::new(r"^WAREHOUSE__(?<index>\d)__ENDPOINT.*").unwrap();

Trying to compile the previous line returns the following:

error[E0015]: cannot call non-const fn `regex::Regex::new` in constants
  |
6 | const REGEXP_WAREHOUSE_ENDPOINT: Regex = Regex::new(r"^WAREHOUSE__(?<index>\d)__ENDPOINT.*").unwrap();
  |                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: calls in constants are limited to constant functions, tuple structs and tuple variants

The same happens with if we change const to static.

error[E0015]: cannot call non-const fn `regex::Regex::new` in statics
 --> src/config.rs:6:43
  |
6 | static REGEXP_WAREHOUSE_ENDPOINT: Regex = Regex::new(r"^WAREHOUSE__(?<index>\d)__ENDPOINT.*").unwrap();
  |                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: calls in statics are limited to constant functions, tuple structs and tuple variants

We need a runtime-initialized variable for the struct. Neither const nor lazy work; time to search for something else.

The `lazy_static` crate

When you need something, there's a high chance somebody required it before. If lucky, they created a crate for it. Case in point, the lazy_static crate provides a solution.

>A macro for declaring lazily evaluated statics in Rust.

>Using this macro, it is possible to have statics that require code to be executed at runtime in order to be initialized. This includes anything requiring heap allocations, like vectors or hash maps, as well as anything that requires non-const function calls to be computed.

>-- lazy_static crate

The usage is straightforward: we wrap the static declaration in a macro.

lazy_static! {
    static ref REGEXP_WAREHOUSE_ENDPOINT: Regex = Regex::new(r"^WAREHOUSE__(?<index>\d)__ENDPOINT.*").unwrap();
}

We achieved what we wanted to. Yet, we can do better.

`LazyLock` for the win

Rust 1.80 adds LazyLock. LazyLock is a built-in exact replacement for the lazy_static macro.

The documentation of LazyLock is straightforward:

>pub struct LazyLock<T, F = fn() -> T> { /* private fields */ }

>A value which is initialized on the first access.

>This type is a thread-safe LazyCell, and can be used in statics. Since initialization may be called from multiple threads, any dereferencing call will block the calling thread if another initialization routine is currently running.

>-- LazyLock

At this point, we can use it directly:

static REGEXP_WAREHOUSE_ENDPOINT: LazyLock<Regex> =
        LazyLock::new(|| Regex::new(r"^WAREHOUSE__(?<index>\d)__ENDPOINT.*").unwrap());

`OnceLock`

As an alternative, one can use OnceLock from Rust 1.70.

>pub struct OnceLock<T> { /* private fields */ }

>A synchronization primitive which can nominally be written to only once.

>This type is a thread-safe OnceCell, and can be used in statics. In many simple cases, you can use LazyLock<T, F> instead to get the benefits of this type with less effort: LazyLock<T, F> "looks like" &T because it initializes with F on deref! Where OnceLock shines is when LazyLock is too simple to support a given case, as LazyLock doesn’t allow additional inputs to its function after you call LazyLock::new(|| ...).

>-- OnceLock

Usage is quite different:

static REGEXP_WAREHOUSE_ENDPOINT: OnceLock<Regex> = OnceLock::new();       //1

let endpoint = REGEXP_WAREHOUSE_ENDPOINT.get_or_init(
        || Regex::new(r"^WAREHOUSE__(?P<index>\d+)__ENDPOINT$").unwrap()); //2

endpoint.find("whatever").is_some()                                        //3

Create the OnceLock
Get or initialize the variable
Use the variable

Summary

In this post, we described several options to create lazy-initialized variables. Before, we had to rely on the lazy_static crate. With Rust 1.80, we can replace it with LazyLock. If you need additional input after the LazyLock::new(), OnceLock is your friend.

To go further:

Originally published at A Java Geek on June 1^st, 2025

High-cardinality values for build flags in Rust

Thu, 17 Apr 2025 08:10:37 +0000

While working on my demo on WebAssembly and Kubernetes, I wanted to create three different binaries based on the same code:

Native: compile the Rust code to regular native code as a baseline
Embed: compile to WebAssembly and use the WasmEdge runtime image as the base Docker image
Runtime: compile to WebAssembly, use a base scratch image as my base image, and set the runtime when running the code

The code itself is an HTTP server that offers a single endpoint. For the sake of the demo, I wanted it to return the flavour of the underlying image.

curl localhost:3000/get

{"source": "native", "data": {}}

The idea is to have a single codebase that I can compile to native or WebAssembly. I solved this requirement by using a cfg compile flag.

#[cfg(flavor = "native")]
const FLAVOR: &str = "native";

#[cfg(flavor = "embed")]
const FLAVOR: &str = "embed";

#[cfg(flavor = "runtime")]
const FLAVOR: &str = "runtime";

// Use FLAVOR later in the returned HTTP response

In my case, I can live with three different values. But what if I had to deal with a high cardinality, say, fifteen? It would be quite a bore to define them manually. I searched for a solution and found Build Scripts.

>Some packages need to compile third-party non-Rust code, for example C libraries. Other packages need to link to C libraries which can either be located on the system or possibly need to be built from source. Others still need facilities for functionality such as code generation before building (think parser generators).

>Cargo does not aim to replace other tools that are well-optimized for these tasks, but it does integrate with them with custom build scripts. Placing a file named build.rs in the root of a package will cause Cargo to compile that script and execute it just before building the package.

>-- Build Scripts

Let's try with a simple build.script at the root of the crate:

fn main() {
    println!("Hello from build script!");
}

cargo build

Compiling high-cardinality-cfg-compile v0.1.0 (/Users/nico/projects/private/high-cardinality-cfg-compile)
 Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s

There isn't any log–nothing seems to happen. The documentation reveals the reason:

>The output of the script is hidden from the terminal during normal compilation.
>If you would like to see the output directly in your terminal, invoke Cargo as "very verbose" with the -vv flag.

Let's compile again with the verbose flag:

cargo build --vv

The output is what we expect:

...
[high-cardinality-cfg-compile 0.1.0] Hello from build script!
...

Now is the time to do something useful: I'll use the build script to replace the hard-coded constants above. For that, I'll generate a Rust code file that contains the value passed for flavor.

Note the build script runs before compilation. Hence, it doesn't have access to the cfg flags. Instead, I'll pass the value as a Cargo.toml package metadata key value.

[package.metadata]
flavor = "foobar"

For our build script to read the Cargo.toml metadata, we need to add a build dependency:

[build-dependencies]
cargo_metadata = "0.19.1"

The code is straightforward:

fn main() {
    let metadata = MetadataCommand::new()                                         //1
        .exec()
        .expect("Failed to fetch cargo metadata");

    let package = metadata.root_package().expect("No root package found");        //2

    let flavor = package                                                          //3
        .metadata
        .get("flavor")
        .and_then(|f| f.as_str())
        .expect("flavor is not set in Cargo.toml under [package.metadata]");

    let dest_path = Path::new("src").join("flavor.rs");                           //4

    fs::write(&dest_path, format!("pub const FLAVOR: &str = \"{}\";\n", flavor))  //5
        .expect("Failed to write flavor.rs");

    println!("cargo:rerun-if-changed=Cargo.toml");
    println!("cargo:warning=FLAVOR written to {}", dest_path.display());
}

Get the metadata
Get the package where we want to create the new file
Read the flavor value
Reference src/flavor.rs
Write pub const FLAVOR: &str = <flavor>

On the code side, we only need to use the FLAVOR const from the flavor module:

mod flavor;

fn main() {
    println!("Hello from flavor {}", flavor::FLAVOR);
}

Running the program outputs the flavor configured in the Cargo.toml file:

cargo run

Hello from flavor foobar

Conclusion

In this, I've shown how to use high-cardinality build parameters from the package metadata. I could have achieved the same with environment variables, but I wanted to learn about the metadata section of the Cargo.toml file.

The build.rs file is a handy trick for achieving goals that aren't possible with regular Cargo features.

To go further:

Build Scripts

Originally published at A Java Geek on April 13^th, 2025

Mastering Borrow Checking in Rust: The Key to Safe and Efficient Memory Management

Fri, 06 Dec 2024 23:26:30 +0000

As a developer, you have probably wrestled with memory management challenges: from the dreaded null pointer dereferences to elusive race conditions in concurrent code.

Rust, with its groundbreaking approach to safety and performance, offers a solution: borrow checking. This unique feature enforces strict ownership and borrowing rules, eliminating common memory errors at compile time without relying on garbage collection.

In this post, I’ll break down the concept of borrow checking, illustrate it with practical examples, and explain why it’s essential for you to master it. By the end, you’ll see why Rust’s borrow checker isn’t just a gatekeeper—it’s a trusted partner in writing safe, efficient code.

What is Borrow Checking?

At its core, borrow checking is Rust’s mechanism for ensuring that references to data are valid and follow strict rules about ownership and mutability. This is part of Rust’s ownership system, which guarantees memory safety by enforcing three key rules at compile time:

Each piece of data in Rust is owned by a single variable at any given time.
Data can be borrowed as:
- One mutable reference (&mut), or
- Any number of immutable references (&), but never both at the same time.
References must always be valid, meaning no dangling pointers.

Borrow checking ensures these rules are upheld. It tracks how data is borrowed and accessed, and it stops us from making unsafe memory access patterns. Let’s delve into why this is important.

Why Does Borrow Checking Matter?

Borrow checking solves problems that plague languages with manual memory management, like C or C++. In those languages, developers must manage memory manually, leading to:

Use-after-free errors: Accessing memory that has already been deallocated.
Dangling pointers: References pointing to invalid memory.
Data races: Simultaneous access to mutable data from multiple threads, causing unpredictable behaviour.

These issues often surface at runtime, making them hard to debug and costly to fix. Rust’s borrow checker prevents these bugs at compile time. It offers the performance benefits of manual memory management while ensuring safety and correctness.

Borrow Checking in Practice

Let’s walk through a series of examples to understand how borrow checking works in Rust and how it enforces ownership and borrowing rules.

Example 1: Immutable Borrowing

Immutable borrowing allows multiple references to the same data, as long as none of them modifies it.

fn main() {
    let data = String::from("Hello, Coderlegion!"); // `data` owns the String
    let borrowed_data = &data; // Immutable borrow
    
    println!("{}", borrowed_data); // Safe access to the borrowed reference
    println!("{}", data); // Safe access to the original owner
}

Key Points:

borrowed_data holds an immutable reference (&data) to data.
Both borrowed_data and data can be accessed concurrently because they don’t modify the underlying data.

Example 2: Mutable Borrowing

When data is borrowed mutably, only one reference is allowed, ensuring exclusive access.

fn main() {
    let mut data = String::from("Coderlegion is amazing!"); // Mutable data
    let borrowed_data = &mut data; // Mutable borrow

    borrowed_data.push_str(" Let's learn borrow checking."); // Modify the data
    println!("{}", borrowed_data); // Safe because access is exclusive
}

Key Points:

&mut data creates a mutable borrow, allowing borrowed_data to modify the data.
While borrowed_data exists, no other references to data—immutable or mutable—are allowed.

Example 3: Mixing Mutable and Immutable Borrows

Rust enforces strict separation between mutable and immutable borrows to prevent conflicts.

fn main() {
    let mut data = String::from("Concurrency made safe!");
    let immut_borrow = &data; // Immutable borrow
    
    let mut_borrow = &mut data; // Mutable borrow - ERROR
    println!("{}", immut_borrow);
}

Compile-Time Error:

error[E0502]: cannot borrow `data` as mutable because it is also borrowed as immutable

Explanation:

Allowing a mutable borrow (mut_borrow) alongside an immutable borrow (immut_borrow) could lead to data races.
Rust’s borrow checker prevents this, ensuring data integrity.

Example 4: Lifetimes and Borrow Checking

Rust extends borrow checking to lifetimes, ensuring references remain valid throughout their usage.

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

fn main() {
    let string1 = String::from("Coderlegion");
    let string2 = String::from("Borrow checker");

    let result = longest(&string1, &string2);
    println!("The longest string is: {}", result);
}

Key Points:

'a' is a lifetime annotation ensuring both x and y live as long as the return value.
This guarantees no dangling references, even when dealing with complex ownership patterns.

How Does Borrow Checking Work Internally?

Rust’s compiler enforces borrow checking through its abstract syntax tree (AST) and control flow analysis:

Ownership Tracking: The compiler tracks which variable owns a piece of data at any point.
Borrow Graphs: References are analyzed for conflicts. For example:
- Immutable references are grouped into a single “read” set.
- Mutable references form an exclusive “write” set.
Lifetime Validation: Rust ensures that references are valid for their declared lifetimes, preventing dangling references.

By performing these checks at compile time, Rust guarantees memory safety without runtime penalties.

Common Borrow Checking Errors and How to Fix Them

Simultaneous Mutable and Immutable Borrows
- Error: "Cannot borrow as mutable because it is also borrowed as immutable."
- Fix: Use only one type of borrow at a time, and drop immutable references before mutable ones.
Dangling References
- Error: "Borrowed value does not live long enough."
- Fix: Ensure the borrowed reference doesn’t outlive its source.
Invalid Lifetimes
- Error: "Cannot return reference to a local variable."
- Fix: Avoid returning references to local variables that will be dropped.

Rust has a steep Learning Curve

Borrow checking might feel restrictive at first. Developers transitioning from other languages may find it challenging to adjust to Rust’s ownership rules. However, these restrictions force us to write safer, more predictable code. Over time, borrow checking becomes second nature and even a guide for designing better systems.

Why Borrow Checking Matters for you and your team.

As we adopt Rust in our projects, borrow checking will become an integral part of our development workflow. Here’s why it matters:

Safety First: Borrow checking eliminates entire classes of bugs at compile time, saving debugging time and ensuring reliability.
Performance Without Garbage Collection: We get the efficiency of manual memory management with the safety of high-level languages.
Concurrency Made Easy: Borrow checking prevents data races, enabling us to write safe concurrent code.

Wrapping Up

Rust’s borrow checker is more than just a set of rules—it’s a tool for writing safe, performant, and maintainable code. By embracing borrow checking, we’re not just avoiding bugs; we’re adopting a mindset of precision and care that will make us better developers.

Let’s continue exploring Rust together. The more you practice, the more intuitive borrow checking will become. If you have questions or need further clarification or drop a comment. Let’s make memory safety a cornerstone of our development culture!

If you found this post helpful, feel free to share it with others. Together, we can master Rust and build robust software that we’re proud of.

About the Author

Mike Dabydeen a Software Development Manager and college professor with over 20 years of experience and a passion for building scalable solutions and fostering growth in the tech community. With expertise in various technologies, he enjoys creating innovative tools and mentoring teams to achieve their goals. Outside of managing projects and teaching, he also writes, in both English & Spanish, about software development, team dynamics, and tech education, while also pursuing personal challenges.

Coder Legion - Recent posts tagged rust-lang

New Rust Tutorial: Structured Logging with tracing

Runtime-initialized variables in Rust

Constants

The lazy_static crate

LazyLock for the win

OnceLock

Summary

High-cardinality values for build flags in Rust

Conclusion

Mastering Borrow Checking in Rust: The Key to Safe and Efficient Memory Management

What is Borrow Checking?

Why Does Borrow Checking Matter?

Borrow Checking in Practice

Example 1: Immutable Borrowing

Example 2: Mutable Borrowing

Example 3: Mixing Mutable and Immutable Borrows

Example 4: Lifetimes and Borrow Checking

How Does Borrow Checking Work Internally?

Common Borrow Checking Errors and How to Fix Them

Rust has a steep Learning Curve

Why Borrow Checking Matters for you and your team.

Wrapping Up

The `lazy_static` crate

`LazyLock` for the win

`OnceLock`