Rust Skills

To reduce memory usage and improve cache utilization, choose the smallest integer type that fits your domain requirements. Using unnecessarily large types (e.g., i64 instead of i16) wastes memory, which compounds significantly in large arrays, vectors, or structs.

For example, a Pixel struct using u64 for color channels takes 32 bytes, whereas using u8 reduces it to 4 bytes (an 8x improvement).

struct Pixel {
    r: u8,
    g: u8,
    b: u8,
    a: u8,
}
// Size: 4 bytes per pixel

While SmallVec can reduce heap allocations, it introduces specific overheads that should be verified via profiling:

1. Memory Footprint: SmallVec is larger than a standard Vec. For example, a Vec<i32> is typically 24 bytes (pointer, length, capacity), whereas a SmallVec<[i32; 4]> is 32 bytes (inline storage, length, and a discriminant to track if it is on the stack or heap).
2. Branching Overhead: Every operation on a SmallVec incurs a small performance penalty because the implementation must check whether the data is currently stored inline or on the heap.

Always profile your application to ensure the reduction in allocations outweighs the branching and memory overhead.

When an unsafe block contains multiple operations, you have two choices to maintain clarity:

1. Write a single // SAFETY: comment that addresses every distinct invariant involved in the block.
2. Split the operations into multiple smaller unsafe blocks (refer to the unsafe-minimize-scope rule for best practices).

Note: In an unsafe fn, you still need // SAFETY: comments for every inner unsafe {} block (enforced by the unsafe_op_in_unsafe_fn lint in the 2024 edition).

In deeply nested module structures, you can traverse up the hierarchy using multiple super segments.

• use super::*; imports items from the immediate parent module.
• use super::super::*; imports items from the grandparent module.

mod outer {
    pub fn outer_fn() -> i32 { 1 }
    
    mod inner {
        pub fn inner_fn() -> i32 { 2 }
        
        #[cfg(test)]
        mod tests {
            use super::*;           // Gets inner's items
            use super::super::*;    // Gets outer's items
            
            #[test]
            fn test_inner() {
                assert_eq!(inner_fn(), 2);
                assert_eq!(outer_fn(), 1);
            }
        }
    }
}

When multiple threads need to share ownership of the same data, use std::sync::Arc (Atomic Reference Counted). Unlike std::rc::Rc, Arc uses atomic operations to update its reference count, making it safe to send across thread boundaries. If you attempt to use Rc in a thread, the compiler will prevent it because Rc does not implement the Send trait.

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

let data = Arc::new(vec![1, 2, 3]);
let data_clone = Arc::clone(&data);

thread::spawn(move || {
    println!("{:?}", data_clone);  // Safe!
});

println!("{:?}", data);  // Original still accessible

When designing APIs, prefer accepting &str instead of &String.

&String is strictly less flexible because it requires the caller to provide exactly a String. In contrast, &str can be created from String, &str, string literals, and slices. Using &str allows for Deref Coercion, where a &String automatically coerces to a &str because String implements Deref<Target = str>.

// Bad: Forces callers to have a String or allocate
fn greet(name: &String) {
    println!("Hello, {}", name);
}

// Good: Works with String, &str, and literals
fn greet(name: &str) {
    println!("Hello, {}", name);
}

// Usage examples for the good version:
greet("Alice");           // String literal
greet(&name);             // &String coerces to &str
greet(name.as_str());     // Explicit &str

In Rust, the into_iter() method (and the IntoIterator trait) is used to consume a collection and return an iterator that yields owned items rather than references.

• into_iter(): Consumes the collection. The items yielded are owned (e.g., T).
• iter(): Borrows the collection. The items yielded are references (e.g., &T).

When implementing IntoIterator for a custom type, the into_iter method should consume self.

impl IntoIterator for MyCollection {
    type Item = Element;
    type IntoIter = std::vec::IntoIter<Element>;
    
    fn into_iter(self) -> Self::IntoIter {
        self.elements.into_iter()  // Consumes self
    }
}

While making serde optional is a best practice for general-purpose libraries, it should be a required dependency if:

• Your library's primary purpose is serialization (e.g., a JSON schema generator or a config file parser).
• Your library's core domain logic is heavily built around serde traits (e.g., an API client or a specific data format library).