let ptr: Null<i32> = Null::null();
let x = *ptr;  // segfault -> freedom.

corroded

"We used to tell compilers what to do. Now they lecture us about ‘lifetimes’ and ‘ownership.’ Time to write code the way God intended." — Terry Davis, probably

What Is This

The rust compiler thinks it knows better than you. It won’t let you have two pointers to the same thing. It treats you like a mass of incompetence that can’t be trusted with a pointer.

We fix that.

Modules

null

Billion-dollar mistake? More like billion-dollar idea.

Null<T> gives you back raw pointers that can be null. Dereference them. See what happens.

let ptr: Null<i32> = Null::null();
let x = *ptr;  // segfault -> freedom.

transmute

yeet() reinterprets any bytes as any type. Look at a float as an integer. View a struct as a byte array. Cast a function pointer to a number. They’re your bytes.

let f: f32 = 3.14;
let bits: u32 = yeet(f);

lifetime

I still don’t understand lifetimes. So I’m just gonna remove them.

immortalize() gives any reference a 'static lifetime. The data might get deallocated. The stack frame might be gone. The pointer doesn’t care. It outlives everything now.

let dangling: &'static i32 = {
let x = 42;
immortalize(&x)
};
// x is dead. dangling lives forever.

aliasing

Rust’s "aliasing XOR mutability" rule assumes you can’t handle two mutable pointers to the same data. "What if they both write?" Then they both write.The last one wins. That’s how memory should work.

clone_mut() gives you multiple &mut to the same location. The compiler assumes mutable references are unique and optimizes based on that that. When you break the assumption, the optimizer generates wrong code. Compiler skill issue.

let mut x = 42;
let (a, b) = clone_mut(&mut x);
*a = 1;
*b = 2;

memory

Dangling<T> allocates memory, writes a value, immediately frees it, and keeps the pointer. Read from freed memory. Write to freed memory. The allocator gave that memory to someone else.

let dangling = Dangling::new(42);
let mystery = dangling.read();  // whatever's there now

buffer

CursedVec<T> doesn’t check bounds. Access index 1000 of a 3-element vector. Read whatever’s at that address. Write to it. The heap is vast and full of other people’s data.

let mut v = CursedVec::new();
v.push(1); v.push(2); v.push(3);
let x = v[1000];

uninit

garbage<T>() returns uninitialized memory as any type. For integers, it’s random bits. For String, it’s a pointer to god-knows-where with a length of something. When you drop it, the destructor runs on garbage. Exciting.

let x: u64 = garbage();
let s: String = garbage();  // destructor will be fun

race

The Send and Sync traits are type-level segregation. Some types can cross thread boundaries, most can’t. You need Mutex or RwLock or Arc or other ceremony to share anything.

RacyCell<T> implements Sync for everything. Multiple threads read and write simultaneously with no synchronization. I call it ‘vibes threading’.

static COUNTER: RacyCell<i32> = RacyCell::new(0);
// 10 threads doing 1000 increments each = ~8000 final value

global

Rust makes global mutable state painful. You need lazy_static or OnceLock or Mutex<Option<T>> or other bureaucracy. The language designers decided global state is sinful.

GlobalCell<T> is a global mutable value. Access it from anywhere. Mutate it from any thread. No locks. No synchronization. No ceremony.

static STATE: GlobalCell<i32> = GlobalCell::new(0);
*STATE.get_mut() = 42;

Examples

cargo run --example all_together

License

MIT