DEV Community: Lori-Shu

Implicit Function or Implicit Type? Demystifying Rust Closures

Lori-Shu — Thu, 22 Oct 2026 14:54:15 +0000

Closure Note

Rust closures often feel like a mysterious monolith, but they were born to solve a fundamental need: first-class functions behavior with state capture.

In conventional linear execution, named functions are invoked immediately. Standard function pointers (fn()) let you store and call functions later, but they lack a crucial capability—they cannot capture or remember variables from their surrounding environment.

That is why closures were introduced to Rust. Although we casually refer to closures as "functions," it is much more accurate to think of them as concrete, compiler-generated types.

How Closures Work Under the Hood

When you write a closure, it captures the variables it needs from its enclosing scope. Behind the scenes, the Rust compiler:

Generates an anonymous, unique type for the closure.

Stores the captured variables inside fields of this generated struct.

Applies borrowing rules: By default, it uses "reborrowing" mechanics identical to regular function calls with reference arguments.

Implements function traits: The compiler automatically implements one of the core closure traits based on how the variables are captured:

Fn: Implemented if the closure only borrows captured variables immutably. It can be called multiple times.

FnMut: Implemented if the closure borrows any variables mutably. It can also be called multiple times, modifying state along the way.

FnOnce: The parent trait of the others. If the closure takes ownership of captured variables (such as via the move keyword) or consumes them, it implements FnOnce and can typically only be executed once.

The Role of the move Keyword

As counterintuitive, closure with move won't take ownership of the instances behind reference types. It just moves the variable into the closure. What is different from closure without move is that the outer variables (with owned or reference types) will be invalid after the closure is constructed.

Because of Rust's rigorous borrow checker, we frequently rely on the move keyword with closures to satisfy lifetime constraints—especially when spawning threads or returning closures from functions. Instead of borrowing variables from the stack, move forces the closure to take ownership of those variables, moving them directly into the compiler-generated struct.

While optimizing Rust code often involves careful lifetime management, mastering how closures handle memory under the hood is a rare and invaluable skill for writing high-performance systems.

To Borrow or To Clone: The Rust Struct Exposure Dilemma

Lori-Shu — Wed, 14 Oct 2026 03:43:23 +0000

Every Rust developer eventually hits a crossroads when trying to expose private struct fields cleanly. Here is a breakdown of the common approaches, their hidden costs, and how to strike the right balance.

1. The Brute-Force Route: Making Fields Public

The most direct fix for visibility issues is simply marking fields pub. While this instantly grants access, it sacrifices encapsulation and can introduce dangerous side effects. Giving outside callers full access means anyone can mutate internal state or even move values out of the struct entirely, risking broken invariants.

2. The Convenience Trap: Overusing Clone

Another route is writing getter methods that return cloned instances. It is frictionless enough that developers sometimes abuse it purely as an escape hatch to silence the borrow checker.

The downside? Cloning performs a deep copy of the underlying memory. If you are exposing large data structures, frequent cloning introduces hidden CPU overhead and memory bandwidth pressure.

3. The Idiomatic Choice: Strategic Borrowing

The high-performance solution is leveraging references and lifetime annotations. Although lifetimes can steepen the learning curve for developers coming from garbage-collected languages, borrowing is vastly more efficient than cloning. No matter how massive the original type is, a reference only copies a pointer-sized footprint.

Yet, zero-cost abstractions demand careful design. Combining complex lifetime bounds with multi-threaded safety and thread-pool concurrency can escalate quickly. Ultimately, writing production-grade Rust comes down to balancing clean borrowing strategies with minimizing resource contention.

From Thread to Task: Modern Concurrency Patterns

Lori-Shu — Thu, 08 Oct 2026 14:48:06 +0000

While conventional OS threading models offer raw parallel execution, modern programming languages have evolved distinct abstractions to overcome thread overhead and ergonomics challenges.

TypeScript & Python: Single-Threaded Event Loops

TypeScript and Python historically embraced a single-threaded event loop architecture, multiplexing execution over a single OS thread to yield non-blocking I/O and "emulated" parallelism without the headache of thread-resource management or lock contention. However, to bypass the CPU bottlenecks of this single-threaded design, Python has recently moved toward true OS-thread concurrency models (i.e., free-threaded CPython).

Go & Java: Managed Green Threads

Go and Java (via Virtual Threads) opted for user-space green-threading models (M:N scheduling), where a fixed pool of carrier OS threads executes millions of lightweight tasks. This drastically boosts throughput while preserving a synchronous, blocking programming style that seamlessly blends with legacy language syntax--bypassing the ecosystem splits common to traditional async models.

Rust: Stackless State Machines

Rust takes a radically explicit approach by compiling async functions into zero-cost, stackless state machines. Async tasks in Rust are typed as Futures—essentially tagged enums representing distinct state transitions. Built around an async/await syntax, Rust futures are passive by default and only execute when explicitly polled by an async runtime/scheduler.

Trade-offs & Abstraction Costs

No single model completely solves concurrency without trade-offs:

The Function Coloring Problem: Both TypeScript and Rust inherit function coloring via async/await, creating friction when bridging synchronous blocking contexts with async runtimes.
Ergonomics & Mental Overhead: Java’s approach can demand additional developer overhead when orchestrating complex future/task pipelines manually.
Implicit Contexts: Go’s seamless approach feels nearly optimal, yet it conceals execution boundaries by making concurrent tasks look identical to standard synchronous functions.

Architectural Decisions: Multi-Process vs. Multi-Threading

Lori-Shu — Wed, 30 Sep 2026 15:47:28 +0000

When designing parallel and concurrent systems, developers invariably face a core architectural dilemma: Multi-Process vs. Multi-Threading.

If you learned systems programming in C, you likely remember fork() and join() (or waitpid()) as the default primitives for spawning and managing execution units. In the early days of Linux, POSIX thread implementations were notoriously fragile, making process cloning the de facto standard for parallelism.

However, as operating systems matured and production-grade threading models stabilized, a massive wave of systems migrated toward multi-threading.

The Case for Multi-Threading

Multi-threaded architectures offer compelling performance and developer-experience advantages:

Seamless Memory Sharing: Sharing state and pointers across threads is fundamentally simpler and cheaper than orchestrating Inter-Process Communication (IPC) mechanisms like shared memory segments, pipes, or Unix domain sockets.
Lower Allocation Overhead: Spawning a thread carries significantly less CPU and memory overhead compared to cloning an entire process address space.
Predictable Lifecycle Management: Thread lifecycles are naturally tied to their parent process. When the host process exits, its threads are cleaned up automatically, reducing the risk of dangling zombie processes or lingering resource leaks.

Why Multi-Process Is Far From Obsolete

Despite the popularity of threads, the multi-process model remains indispensable for specific high-assurance workloads:

Error Isolation & Fault Tolerance: A panic, segmentation fault, or unhandled exception in a worker thread can crash the entire application. In contrast, a crashed process dies in isolation, leaving the primary supervisor running intact—making it ideal for sandboxing and plugin ecosystems (e.g., modern web browsers).
Granular Observability & Debugging: Because each child process operates with a distinct PID, OS-level tools like htop, perf, and strace can monitor resource usage, memory footprints, and system calls per unit much more cleanly than inside a dense multi-threaded runtime.
Language-Specific Workarounds: In languages constrained by a Global Interpreter Lock (GIL)—such as Python or Ruby—multi-processing remains the primary strategy for bypassing single-core bottlenecks to achieve true multi-core utilization.

Summary

Neither pattern is inherently superior; the optimal choice depends on your application's constraints:

Reach for Multi-Threading when performance, shared memory access, and low latency are your top concerns.
Reach for Multi-Processing when safety, crash resilience, and strict fault isolation outweigh the overhead of IPC.

Shrinking Your Rust Allocations: Replacing Vec and String with Boxed Slices

Lori-Shu — Mon, 28 Sep 2026 16:00:43 +0000

When building high-performance systems in Rust, managing dynamic allocations efficiently is key to keeping your memory footprint lean.

Developers often reach for Vec<T> and String by default whenever they need owned collections. However, if data is read-only after creation—such as static assets, loaded images, or unmodifiable configuration strings—holding onto expandable collections wastes unnecessary bytes on the stack.

By "downgrading" fixed-size collections from dynamic types like Vec<T> and String to boxed slices like Box<[T]> and Box<str>, you can trim excess heap metadata without sacrificing ownership.

Why Box<[T]> Beats Vec for Static Data

A Vec<T> and a String carry 24 bytes of stack metadata (on 64-bit systems):

A heap pointer (8 bytes)

The current length (8 bytes)

The allocated capacity (8 bytes)

Because dynamic vectors must support growing and shrinking, they maintain spare capacity. But if your data is loaded once and never resized, tracking capacity is unnecessary overhead.

Converting to a boxed slice (Box<[T]> or Box<str>) drops the capacity field entirely, shrinking stack metadata down to 16 bytes (pointer + length). Across thousands of instances, this metadata reduction adds up quickly.

Practical Implementation

Here is how you can convert dynamic types into boxed slices using .into_boxed_slice() and .into_boxed_str():

use std::path::Path;

pub struct NamedImage {
    buf: Box<[u8]>,
    name: Box<str>,
}

impl NamedImage {
    pub fn new(img_path: &Path, img_name: String) -> Self {
        // Load raw image data and shrink allocation from Vec<u8> to Box<[u8]>
        let buf = image::load_png(img_path).into_boxed_slice();

        // Convert owned String to Box<str>, dropping capacity overhead
        let name = img_name.into_boxed_str();

        Self { buf, name }
    }
}

When .into_boxed_slice() or .into_boxed_str() is called, Rust reallocates or re-slices the heap allocation to match the exact length of the data, freeing any excess capacity back to the allocator.

Beyond &self and &mut self: Rust’s Underrated Method Receivers

Lori-Shu — Sun, 27 Sep 2026 16:51:34 +0000

If you write Rust, you interact with &self and &mut self every single day. They are the backbone of idiomatic Rust, signaling at a glance whether a method reads from or mutates an instance.

However, Rust’s ownership and type system goes deeper than just standard references. Tucked inside the language specification is arbitrary self types—allowing specialized receivers like self: &Arc and self: &Mutex.

While rare in everyday application code, these self-types are power tools when architecting concurrent and multi-threaded systems.

The Standard Receivers: A Quick Refresh

Before diving into the exotic variants, here is how the standard receivers behave:

&self (Shared Reference): Borrow the instance immutably. Multiple callers can execute this method simultaneously without mutating state.

&mut self (Exclusive Reference): Borrow the instance mutably. Guarantees exclusive access to modify the object's internal fields.

self (By Value): Consume the instance, taking full ownership and moving it into the method.

The Power Receivers: &Arc and &Mutex

In concurrent Rust, state is frequently wrapped inside thread-safe smart pointers or synchronization primitives—most notably Arc<T> (Atomic Reference Counting) and Mutex<T>.

Normally, calling a method on an Arc requires cloning the Arc explicitly before calling a standard method:

// Traditional approach
let shared_node = Arc::new(MyNode::new());
MyNode::process_node(shared_node.clone());

By explicit receiver typing, you can make the method itself demand the smart-pointer wrapper directly on self:

impl MyNode {
    // Requires the caller to pass a reference to the Arc wrapping this instance
    pub fn spawn_task(self: &Arc<Self>) {
        let clone = Arc::clone(self);
        tokio::spawn(async move {
            clone.do_work();
        });
    }
}

How do I encapsulate a tool type in Rust?

Lori-Shu — Mon, 31 Aug 2026 14:05:56 +0000

I’ve been wrapping a few tool types in a Rust project lately and ran into some friction. Along the way I picked up a few practical lessons on what a clean tool type should look like. Here’s what I landed on:

Decouple unrelated fields:
The first and hardest step is deciding which fields the type actually owns. Real-world code is full of types that do more than they should; those extra responsibilities are usually candidates for being pulled out.

Prefer immutable interfaces:
A good tool type should expose only immutable methods so callers never need a mutable handle. Rust’s type system pushes you in this direction, and following it let me drop a lot of interior-mutability wrappers I had previously needed at runtime.

Distinguish different kinds of output:
Some values are fixed once the type is created; others change over time. The former can stay as plain owned types, while the latter are better expressed as shared types. I also try to avoid handing out mutable references. When mutation is required, specific methods should own that responsibility.

Insight:
A surprising amount of this is already enforced by the Rust type system. The rules can feel strict, but treating the compiler as a collaborator usually leads to cleaner design and less code.

Introduction to Experiment Indicators

Lori-Shu — Mon, 24 Aug 2026 15:43:57 +0000

Scientific experiments typically need clear indicators to measure and quantify performance. This is especially true in data-processing contexts, where several key metrics deserve close attention.
We can start with a few fundamentals familiar from high-school math: the average (mean), the mode, and the variance. The average corresponds to the "expectation" discussed in probability courses; it summarizes the overall property of a dataset in a single number. The mode is simply the value that appears most frequently. Variance indicates stability—if a dataset shows large variance, it is considered unstable.
Residual is another useful indicator. It measures the difference between data points that have a time-domain character. Residuals are particularly valuable in signal processing, where data are typically ordered by time. They are calculated by taking the difference between values at separate time points.
From residual we derive RSS (Residual Sum of Squares), also known as SSE (Sum of Squared Errors). RSS is obtained by squaring each residual and then summing the results. RMSE (Root Mean Squared Error) takes this a step further: it divides the RSS by the number of data points and then takes the square root. The result has the same magnitude as the original data and effectively represents the average residual. RMSE is especially powerful when the data contain both positive and negative values, because squaring prevents opposing residuals from canceling each other out.

The Trend of Modern Programming Languages

Lori-Shu — Sun, 23 Aug 2026 16:06:05 +0000

In 2026, programming languages—the core tools of software engineers—are undergoing a clear and accelerating shift: they are becoming more static.
Two major design paradigms have long shaped language design. On one side are the static-first languages such as C and Rust. These typically feature strong type systems and sophisticated, heavyweight compilers. On the other side are the dynamic-first languages such as Python and JavaScript. They traditionally rely on weaker type systems while leveraging powerful, professionally engineered runtimes.

Insight:The current trend is unmistakable: languages that once embraced dynamic features are steadily adopting more static characteristics. Many of them have borrowed ideas and mindsets from languages like Rust. Evidence shows that this shift delivers tangible benefits—faster startup times, reduced runtime memory usage, and greater code determinism.
Recognizing this evolution helps us better understand the interplay between static and dynamic elements in our own software. The practical recommendation is straightforward: prefer static approaches whenever possible, and only fall back to dynamic solutions when something is genuinely difficult to make static.

Google's Latest Talent Rearrangement

Lori-Shu — Thu, 06 Aug 2026 15:35:09 +0000

Earlier today, Jeff Dean announced his departure from Google. Who is Jeff Dean? He is one of the most influential figures in Google's history and one of the company's two legendary chief engineers. As a core technical leader, his departure sends a clear signal that Google is undergoing a significant internal talent transition. Since joining Google in 1999, Jeff Dean has contributed to nearly every major product and infrastructure initiative developed by the company. Let's revisit his remarkable journey at Google.
For general users worldwide, Jeff Dean's influence can be seen across many Google products, including Google Search, Gmail, Google Translate, YouTube, Chrome, and Gemini. Some of these products were developed directly under his technical leadership, and they have collectively shaped the digital experiences of billions of users.
For developers and engineers, Jeff Dean is widely regarded as a pioneer of large-scale computing. He played a key role in designing foundational frameworks and systems such as MapReduce, BigTable, GFS (Google File System), Pregel, and TensorFlow. Several of these innovations later inspired influential open-source projects, including Apache Hadoop MapReduce, bringing large-scale computing capabilities to developers around the world.
Insight: Jeff Dean's departure comes amid ongoing speculation about internal disagreements among Google's senior leadership. While Google may be losing one of its legendary technical figures, the broader technology ecosystem continues to benefit from the contributions of pioneers like him. The impact of such talents extends far beyond any single company, ultimately advancing the progress of the entire industry.

The Basic Animation Mechanism in Egui

Lori-Shu — Sat, 11 Jul 2026 14:02:27 +0000

As an immediate-mode UI framework, egui handles animations in a fundamentally different way from traditional retained-mode UI frameworks. Instead of maintaining an explicit animation object, egui provides helper functions such as ui.animate_bool_with_time() -> f32 to track animation progress internally.
The method takes three arguments: an Id (a unique identifier for the animation state), a Boolean flag, and a duration specified as a 32-bit floating-point value. Internally, the egui runtime caches a floating-point state associated with the given Id. This value smoothly transitions from 0.0 to 1.0, or reverses from 1.0 back to 0.0, depending on the state change of the Boolean flag.
During each repaint cycle, egui retrieves the cached animation state using the corresponding Id and updates its progress. The Boolean flag determines the animation direction, while the returned floating-point value represents the current animation progress. Developers can then use this value to control rendering parameters, such as opacity, position, or size.
Insight: Although egui's built-in animation functions are convenient, they are not always sufficient for more sophisticated animation requirements. In such cases, developers should manually manage animation progress using ui.time(). These helper animation functions implicitly maintain internal state, such as a floating-point progress variable, behind the scenes. Understanding this underlying mechanism is essential for designing more advanced animations and for gaining a deeper understanding of egui's immediate-mode paradigm.

The Transition from Code to Standard

Lori-Shu — Wed, 08 Jul 2026 16:09:37 +0000

Some software eventually evolves into an official standard. The word standard itself implies that such software has been recognized as authoritative, reliable, and widely accepted. A good example is the Opus audio codec, which was originally developed by the Xiph.Org Foundation and later standardized as an IETF (Internet Engineering Task Force) RFC. Standardization greatly accelerated the adoption of Opus, allowing it to become one of the most widely used audio codecs on the Internet.
Achieving this transition from code to standard is far from easy. Software intended for standardization must be implemented with exceptional quality, accompanied by clear specifications, and undergo extensive technical review and multiple rounds of discussion and voting before it is accepted by organizations such as the IETF.
Insight. Software that has become part of an official standard provides excellent learning material for developers. It demonstrates not only how to write high-quality code, but also how to design software that is robust, interoperable, and maintainable. As developers, striving to produce work that is eventually worthy of standardization is a meaningful long-term goal.