There is a satisfaction in watching a release that is less about flashy new syntax and more about finally shipping the things people have been waiting on for years.

Rust 1.100 is one of those. The never type, custom allocators, proper dependency cooldowns, and cargo install finally respecting lockfiles by default do not read like marketing copy.

They read like the accumulated pressure of real production use finally forcing the language and tooling to close long-standing gaps.

The never type is the clearest signal of maturity.

An uninhabited type is not glamorous. It is the kind of feature that only becomes urgent once enough people have written enough careful code to feel its absence.

Being able to express this path cannot produce a value cleanly, and having pattern matching understand that impossibility, is the sort of correctness that compounds.

It is the difference between hoping the type system will help and knowing it will. The same spirit shows up in the allocator work and the unused-dependency warnings. These are not features that make demos prettier. They are features that make large codebases more honest about what they actually depend on and how they manage memory.

The supply-chain pieces matter more than most people will admit out loud.

Minimum publish age and the change to cargo install are direct responses to the last few years of registry attacks and the quiet risk of installing something that resolved differently than the author intended.

Cooldowns are imperfect. A patient attacker can still wait them out. But the existence of a configurable delay, combined with lockfile fidelity on install, is the language admitting that the ecosystem is now large enough to be a real target.

That admission is healthier than pretending every new crate version is automatically trustworthy.

The thread’s other recurring complaints are equally telling. They are the price of the guarantees people actually use.

The same type system and monomorphization that make the never type and custom allocators useful also generate work the compiler cannot simply ignore.

People who live in large Rust codebases know this trade-off intimately.

The fact that the release notes and the conversation still spend energy on incremental compile improvements and disk hygiene shows the project has not stopped caring about the daily friction even while it ships foundational language features.

What I take from 1.100 is not that Rust has solved its hard problems.

It is that the hard problems are now the right ones. The language is past the point of needing to prove it can be safe and fast.

It is in the long middle period where the work is making the safety and speed practical at scale, under real dependency graphs, with real attackers, and with real engineers who still have to wait for the compiler.

That is less exciting than a shiny 2.0, and more useful.

Rust 1.100 Feels Like a Language Growing Up in Public was originally published in Rustaceans on Medium, where people are continuing the conversation by highlighting and responding to this story.

You’ve been programming Rust wrong.

Writing proper Rust is not a skill everyone has. Don’t worry though — you can still learn. You can write more performant code, yes, but more importantly, cleaner code.

In general, there are two main types of Rust programmers; both are wrong. Let me demonstrate with an example.

What Not to Do

We have the task of finding the max depth of a binary tree.

The first programmer writes the following:

pub fn max_depth(root: Option<Rc<RefCell<TreeNode>>>) -> i32 {
    let mut stack = vec![(root, 0)]; //(node, current depth)
    let mut max_depth = -1;
  
    while let Some((node, depth)) = stack.pop() {
        match node {
            None => max_depth = std::cmp::max(max_depth, depth),
            Some(c) => {
                stack.push((c.borrow().left.clone(), depth+1));
                stack.push((c.borrow().right.clone(), depth+1));
            }
        }
    }

    max_depth
}

This is not wrong code…but is this clean code?

Most definitely not. Even with all of Rust’s syntactic sugar —matches and while-lets — it’s still verbose and hard to skim.

The root of all unreadable code, frequently, is the use of imperative programming. It’s easy to write and easy to execute, but it rarely leads to good-looking code.

And Rust — with its claim of “supporting multiple paradigms” — does not help. Just because one has access to multiple paradigms doesn’t mean that there isn’t an objectively best paradigm for a task.

In this case, as in many, that objectively best paradigm is Functional Programming. Just take Haskell as an example: when you’re bound to recursions and first-class functions, you’re forced to write code that reads like English.

Let’s Try A Functional Approach

Our problem can easily be written as a recursion:
MaxDepth(tree) = 1+max(MaxDepth(tree.left), MaxDepth(tree.right))

We use this to write a functional programming approach:

pub fn max_depth(root: Option<Rc<RefCell<TreeNode>>>) -> i32 {
    match root {
        None => 0,
        Some(r) => std::cmp::max(
            max_depth(r.borrow().left.clone()),
            max_depth(r.borrow().right.clone())
        ) + 1
    }
}

In fact, this is exactly what the second programmer would write.

It’s more readable and it’s still performant — time complexity is O(# nodes) and space complexity is O(1) (as long as you don’t think too hard).

But we can do so much better.

This…this is not pure functional programming — it’s functional programming inspired, and the readability suffers as a result. I mean, please — can you really say that it’s concise when it repeats max_depth(r.borrow().left.clone()) twice almost word-for-word?

And it’s not even pure: each call to Rc.clone() has side effects (specifically, incrementing a reference counter).

So, what do we do?

A Real Functional Programming Solution

We cannot paint a masterpiece from a faulty canvas. We need to start from scratch to build a perfect solution.

The problem with Rust is every resource your program relies on comes with bloat. Even something that’s supposed to be lightweight, like an i32 comes packaged with bounds checks and a variety of builtin functions — we are advanced developers; we don’t need training wheels.

So let’s start with a clean slate: unit structs.

struct Zero;
struct Succ<N>(N);

Unit structs are like ghosts. They disappear on compilation, costing us nothing: Rust’s promised 0-cost abstractions.

With two lines, we have created numbers:
- Zero represents 0
- Succ (short for Successor) takes N and returns N + 1

But wait, something’s wrong, you cry. Structs are types, not functions or values! What are you even saying!?

I see nothing wrong with that. I mean, does this not look like a number to you?

type One = Succ<Zero>;
type Two = Succ<One>; //or Succ<Succ<Zero>>

But don’t worry yourself too much; after all, in functional programming, are types and functions and values really any different from each other? And what does it matter as long as the code is correct and readable?

Fair, you say, but still: types only exist until compilation. How are we to get any work done with these “numbers” if they disappear on execution?

Remember, Rust has a powerful type system.

Teaching The Compiler to Compare Two Numbers

Sometimes, when explaining Rust, people say traits are like interfaces. This explanation couldn’t be more incorrect.

No; the developer that truly understands Rust knows that traits are mappings between specific input types and output types — basically functions that take and return types.

Let me show you by implementing a Max trait that returns the greater of two of our numbers.

There are 4 cases:
- Max(0,0)=0
- Max(N+1, 0)=N+1
- Max(0, N+1)=N+1
- Max(A+1, B+1)=Max(A,B)+1

This is valid because we have only implemented 0 and Succ; it is impossible to input negative numbers, so A,B,N≥0. Yet again we see the elegance of Rust’s Type System: when we define things ourselves, we have less to deal with.

You know, I was actually thinking of starting a petition to make Rust’s Type System the 8th Wonder of the World — let me know if you’d be interested in signing.

The code is simply English decorated with light dressings of syntax:

trait Max<A, B> {
    type Output;
}

impl Max<Zero,Zero> for () {
    type Output = Zero;
}

impl<N> Max<Zero,Succ<N>> for () {
    type Output = Succ<N>;
}

impl<N> Max<Succ<N>, Zero> for () {
    type Output = Succ<N>;
}

impl<A,B, SubMax> Max<Succ<A>, Succ<B>> for ()
where (): Max<A,B, Output=SubMax> {
    type Output = Succ<SubMax>;
}

Beautiful, isn’t it?

Don’t get distracted, though, we want to find the maximum depth of a tree.
For that, we need a tree in the first place.

So, in just 2 lines, we must declare:

Let There Be Trees.

struct Node<L, R>(L, R);
struct Nil;

Now we have exactly what we need (and only what we need).

Numbers, trees, and a max function., all without stack allocations, heap allocations, and useless function frames… lightweight and efficient, as all things should be.

Everything is immutable, so no borrow checker biting at our heels (not like it ever enforced cleaner code in the first place).

We finally weave everything together into one trait.

From before,
MaxDepth(Tree) = Max(MaxDepth(Tree.Left), MaxDepth(Tree.Right))+1

The code is child’s play:

trait MaxDepth<T> {
  type Output;
}

impl MaxDepth<Nil> for () {
    type Output = Zero;
}

impl<L, R, LDepth, RDepth, SubDepth> MaxDepth<Node<L, R>> for ()
where
    (): MaxDepth<L, Output=LDepth>,
    (): MaxDepth<R, Output=RDepth>,
    (): Max<LDepth, RDepth, Output=SubDepth> {
        type Output = Succ<SubDepth>;
}

That is everything — isn’t it elegant?

Let us test it:

fn main() {
    type MyTree = Node<Node<Node<Nil,Nil>,Nil>,Node<Nil,Nil>>;

    type MaximumDepth = <() as MaxDepth<MyTree>>::Output;
    println!("{}", type_name::<MaximumDepth>());
}

Running this, we get:

 main::Succ<main::Succ<main::Succ<main::Zero>>>

Succ<Succ<Succ<Zero>>> is 3, exactly the depth of our tree!

Not only is our implementation readable and correct, it’s also extremely performant: types are resolved at compile time. The final code simply holds the result as a static string, so runtime performance is O(1) for both time and memory!

And the best part is the program is self-documenting. If someone doesn’t understand how Max works, they don’t need to parse obscure, out of date documentation on the web — they can just scroll up and read the rules themselves.

I know, you’re amazed, but you still might have one final question: if Rust resolves types at compile time, we must know the input at compile time. How would we calculate the depth of a tree only known at runtime?

The Final Step

This is a genuine issue with the Rust language (though I believe there are people working to resolve this disconnect between true Rust and imperfect code).

For now, all we can do is a helper file—nothing out of the ordinary, really: you know what I’m talking about if you’ve ever seen a professional Rust codebase:

use std::fs;
use std::process::Command;

fn replace_line(content: &str, index: usize, text: &str) -> String {
    //even if circumstances prevent us from being perfectly pure,
    //we can still give our best shot
    content.lines()
        .enumerate()
        .map(|(i, line)| if i == index { text } else { line })
        .collect::<Vec<_>>()
        .join("\n")
    }

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let tree = "Node<Nil, Node<Nil, Nil>>";
    
    //a good Rust developer knows to wrap impure code in unsafe
    //this helps isolate code that could cause errors
    unsafe {
        let content = fs::read_to_string("main.rs")?;

        //overwrite the previous definition of MyTree, at line 53:
        let updated = replace_line(
            &content,
            53,
            &format!("\ttype MyTree = {};", tree)
        );
        
        fs::write("main.rs", updated)?;

        let _ = Command::new("rust/rustc/bin/rustc")
            .arg("main.rs")
            .output()
            .expect("Missing copy of rustc in /rust/rustc; please install so that the purity of this program can be maintained.");        
        
        let output = String::from_utf8_lossy(
            &Command::new("./main")
                .output()
                .unwrap()
                .stdout
            )
            .trim_end()
            .to_string();

        println!("Depth: {}!", output);
    }

    Ok(())
}

Some of you may object: this isn’t functionally pure! Running commands and writing to files interact with the operating system, which means side effects!

1. We’ll package a separate copy of rustc as part of the program to ensure easy maintainability. rustc is essentially a function applied on files; it’s basically pure.
2. Writing to files is impure, yes. It really does make the code ugly. Until they release a fully functionally-pure computer (fingers crossed for 2027) we have no other choice than to properly notate impure code with unsafe.

So, our program is done.

One More Word of Advice

With complicated calculations, Rust’s compiler may sometimes return this neat little error message:

error[E0275]: overflow evaluating the requirement `(): Max<Zero, Succ<_>>`
  --> main.rs:56:32
   |
56 |     println!("{}", type_name::<MaximumDepth>());
   |                                ^^^^^^^^^^^^
   |
   = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`pure_sol`)
note: required for `()` to implement `Max<Succ<Zero>, Succ<Succ<_>>>`
  --> main.rs:27:19
   |
27 | impl<A,B, SubMax> Max<Succ<A>, Succ<B>> for ()
   |                   ^^^^^^^^^^^^^^^^^^^^^     ^^
28 | where (): Max<A,B, Output=SubMax> {
   |                    ------------- unsatisfied trait bound introduced here
   = note: 125 redundant requirements hidden
   = note: required for `()` to implement `Max<Succ<Succ<Succ<Succ<Succ<Succ<Succ<Succ<Succ<Succ<...>>>>>>>>>>, ...>`
note: required for `()` to implement `MaxDepth<Node<Node<Nil, Nil>, Nil>>`
  --> main.rs:44:38
   |
44 | impl<L, R, LDepth, RDepth, SubDepth> MaxDepth<Node<L, R>> for ()
   |                                      ^^^^^^^^^^^^^^^^^^^^     ^^
...
48 |     (): Max<LDepth, RDepth, Output=SubDepth> {
   |                             --------------- unsatisfied trait bound introduced here
   = note: 1 redundant requirement hidden
   = note: required for `()` to implement `MaxDepth<Node<Node<Node<Nil, Nil>, Nil>, Node<Nil, Nil>>>`
   = note: the full name for the type has been written to 'main.long-type-1146034684176798783.txt'
   = note: consider using `--verbose` to print the full type name to the console

For some reason, Rust enforces a recursion limit (why would you ever want less of a good thing?). Luckily for us, though, we can change it to our will. I’d strongly recommend putting

![recursion_limit="18000000000000000000"]

before every single program to do away with this nonissue.

Why stop at 18,000,000,000,000,000,000?

Any higher and the Rust compiler complains that the “limit is too large” — which surely must be a mistake; I’m planning on submitting an issue to Rust’s GitHub sometime this week.

Conclusion

This type of programming is not for everyone, but if you’ve made it this far you clearly have potential.

You know to stop relying on the training wheels — loops, mutation — and you know how to derive the things you need instead using unnecessary bloated alternatives. All that’s left is to go forth and write some production-ready code!

The article’s code is available here for reference in your own projects.

Sincerely,
Ein Monarch.

Rust’s Type System Is All You Need was originally published in Rustaceans on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every few months the same line appears: Rust is fine, but when you need real performance on bare metal you reach for C, and the people who care about memory safety get predictably loud about it.

The eye-roll emoji is doing a lot of work. I have written enough of both languages to feel the pull of the claim and the fatigue of the reaction.

C still wins certain arguments cleanly. The abstract machine is thin. The compiler is a thin translator. You can reason about every load and store without a borrow checker or a runtime intervening.

On constrained hardware, or in the deepest layers of an operating system, that transparency remains valuable.

When the problem is literally make this interrupt handler do the absolute minimum work possible, C’s lack of ceremony is not a bug. It is the point.

Where the statement starts to fray is the word optimal. Optimal for what, measured over what lifetime, and paid for by whom? Peak micro-benchmark numbers are easy to chase.

The harder numbers are the ones that appear after the code has lived for years: the time spent hunting use-after-free bugs, the security advisories that keep arriving, the quiet tax of undefined behavior that only surfaces under a particular compiler flag or CPU model.

Rust’s ownership model is not free either.

It forces decisions earlier and sometimes makes the code uglier. In return it removes entire classes of mistakes that C simply leaves on the table for the programmer to manage forever.

On bare metal the difference is not theoretical.

Several production kernels and embedded systems now ship significant amounts of Rust precisely because the performance cost was measured and found acceptable, while the safety benefit was not.

The great power, great responsibility line is accurate and incomplete at the same time.

C does give power. The responsibility part is usually paid by someone else later.

Treating that deferred cost as a badge of seriousness is a cultural habit more than an engineering one.

The better habit is to decide, for each layer of the stack, whether the power is worth the ongoing cognitive and operational load.

I still reach for C when the constraints demand it. I reach for Rust when the same constraints can be met without accepting preventable classes of failure.

The interesting work is knowing which trade-offs you are actually making and being honest about who will pay for them.

C Is Based. Rust Is Just Coping was originally published in Rustaceans on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is a copy of our weekly Rust email newsletter.

If you’d like to receive these emails in your inbox, you can subscribe on Substack.

Meanwhile, you can read the article through the link down below

🦀 Systemd Finally Lets Rust In

🦀 Systemd Finally Lets Rust In was originally published in Rustaceans on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reading the Linux 6.14 progress report from the Asahi team feels like watching a group of engineers finally get room to breathe after years of carrying an entire platform on their backs.

The numbers alone tell the story: more than ninety thousand lines added across twelve hundred and fifty patches, plus the usual constellation of downstream forks for U-Boot, Mesa, virglrenderer, and Flatpak.

That is a full-time job that never ends, especially when every upstream Rust abstraction merge forces another painful rebase.

What stands out is the deliberate shift in priorities.

After the administrative dust settled from the leadership change, the team put the glamorous work on hold and focused on the unglamorous necessity of getting code accepted upstream.

The ISP driver, the Touchbar controllers, the TAS amplifier extensions, the steady stream of smaller fixes: these are the patches that actually reduce the maintenance tax.

Anyone who has maintained a long-lived out-of-tree driver knows exactly how corrosive that tax becomes.

Janne’s ongoing work keeping the patch set alive against an accelerating Rust abstraction cadence is the kind of thankless effort that decides whether a project survives or collapses under its own weight.

The microphone support is the part that feels most characteristically Asahi.

Reverse-engineering the Always-On Processor, writing a stub for the Secure Enclave, then building Triforce because three closely spaced PDM microphones are otherwise useless.

The story of wrestling with immature scientific libraries in Rust, dusting off high-school maths and university statistics, and ending up with something that actually works on the first try is pure engineering satisfaction.

It is the opposite of the polished demo. It is the messy, iterative reality of making hardware that was never designed for you behave like it belongs.

Community funding has changed the equation.

Buying the next Mac no longer means deciding between hardware and rent.

CI infrastructure that should have existed years ago is finally possible. The project can show up at conferences without financial stress.

That is the difference between a volunteer effort that burns people out and a sustainable effort that can keep shipping.

The real measure of progress is the shrinking delta between what Asahi carries and what the mainline kernel already contains.

Every accepted driver, every cleaned-up abstraction, every bit of maintenance load removed is a step toward the day when Asahi becomes just another set of well-supported Apple Silicon platforms instead of a heroic parallel tree.

That is the work that matters, and it is the work they are choosing to do first.

Reference:

Progress Report: Linux 6.14 - Asahi Linux

Asahi Linux’s Grind Toward the Mainline was originally published in Rustaceans on Medium, where people are continuing the conversation by highlighting and responding to this story.