2025-12-11 08:00:00
Bringing Rust into the Linux kernel is one of the most ambitious modernization efforts in open source history. The Linux kernel, with its decades of C code and deeply ingrained development practices, is now opening its doors to a memory-safe language. It’s the first time in over 30 years that a new programming language has been officially adopted for kernel development. But the journey is far from straightforward.
In this episode, we speak with Danilo Krummrich, Linux kernel maintainer and Rust for Linux core team member, about the groundbreaking work of integrating Rust into the Linux kernel. Among other things, we talk about the Nova GPU driver, a Rust-based successor to Nouveau for NVIDIA graphics cards, and discuss the technical challenges and cultural shifts required for large-scale Rust adoption in the kernel as well as the future of the Rust4Linux project.
CodeCrafters helps you become proficient in Rust by building real-world, production-grade projects. Learn hands-on by creating your own shell, HTTP server, Redis, Kafka, Git, SQLite, or DNS service from scratch.
Start for free today and enjoy 40% off any paid plan by using this link.
Rust for Linux is a project aimed at bringing the Rust programming language into the Linux kernel. Started to improve memory safety and reduce vulnerabilities in kernel code, the project has been gradually building the infrastructure, abstractions, and tooling necessary for Rust to coexist with the kernel’s existing C codebase.
Danilo Krummrich is a software engineer at Red Hat and a core contributor to the Rust for Linux project. His fundamental contribution to Rust for Linux is the driver-core infrastructure, the foundational framework that makes it possible to write drivers in Rust at all. This includes both C and Rust code that provides the core abstractions for device drivers in the kernel. Danilo is a maintainer for multiple critical kernel subsystems, including Driver Core, DRM (GPUVM, Rust, GPU Scheduler), GPU drivers for NVIDIA GPUs (Nova, Nouveau), Firmware Loader API, as well as Rust bindings for PCI, DMA, and ALLOC. He is the primary developer of the Nova GPU driver, a fully Rust-based driver for modern NVIDIA GPUs.
2025-11-27 08:00:00
What does it take to rewrite the foundational components of one of the world’s most popular Linux distributions? Ubuntu serves over 12 million daily desktop users alone, and the systems that power it, from sudo to core utilities, have been running for decades with what Jon Seager, VP of Engineering for Ubuntu at Canonical, calls “shaky underpinnings.”
In this episode, we talk to Jon about the bold decision to “oxidize” Ubuntu’s foundation. We explore why they’re rewriting critical components like sudo in Rust, how they’re managing the immense risk of changing software that millions depend on daily, and what it means to modernize a 20-year-old operating system without breaking the internet.
CodeCrafters helps you become proficient in Rust by building real-world, production-grade projects. Learn hands-on by creating your own shell, HTTP server, Redis, Kafka, Git, SQLite, or DNS service from scratch.
Start for free today and enjoy 40% off any paid plan by using this link.
Canonical is the company behind Ubuntu, one of the most widely-used Linux distributions in the world. From personal desktops to cloud infrastructure, Ubuntu powers millions of systems globally. Canonical’s mission is to make open source software available to people everywhere, and they’re now pioneering the adoption of Rust in foundational system components to improve security and reliability for the next generation of computing.
Jon Seager is VP Engineering for Ubuntu at Canonical, where he oversees the Ubuntu Desktop, Server, and Foundations teams. Appointed to this role in January 2025, Jon is driving Ubuntu’s modernization strategy with a focus on Communication, Automation, Process, and Modernisation. His vision includes adopting memory-safe languages like Rust for critical infrastructure components. Before this role, Jon spent three years as VP Engineering building Juju and Canonical’s catalog of charms. He’s passionate about making Ubuntu ready for the next 20 years of computing.
cat
2025-11-13 08:00:00
Building a new programming language from scratch is a monumental undertaking. In this episode, we talk to Richard Feldman, creator of the Roc programming language, about building a functional language that is fast, friendly, and functional. We discuss why the Roc team moved away from using Rust as a host language and instead is in the process of migrating to Zig. What was the decision-making process like? What can Rust learn from this decision? And how does Zig compare to Rust for this kind of systems programming work?
CodeCrafters helps you become proficient in Rust by building real-world, production-grade projects. Learn hands-on by creating your own shell, HTTP server, Redis, Kafka, Git, SQLite, or DNS service from scratch.
Start for free today and enjoy 40% off any paid plan by using this link.
Roc is a fast, friendly, functional programming language currently in alpha development. It’s a single-paradigm functional language with 100% type inference that compiles to machine code or WebAssembly. Roc takes inspiration from Elm but extends those ideas beyond the frontend, introducing innovations like platforms vs applications, opportunistic mutation, and purity inference. The language features static dispatch, a small set of simple primitives that work well together, and excellent compiler error messages. Roc is already being used in production by companies like Vendr, and is supported by a nonprofit foundation with corporate and individual sponsors.
Richard Feldman is the creator of the Roc programming language and author of “Elm in Action.” He works at Zed Industries and has extensive experience with functional programming, particularly Elm. Richard is also the host of Software Unscripted, a weekly podcast featuring casual conversations about code with programming language creators and industry experts. He’s a frequent conference speaker and teacher, with courses available on Frontend Masters. Richard has been a longtime contributor to the functional programming community and previously worked at NoRedInk building large-scale Elm applications.
Arc::bump(), which is an alias for clone().2025-11-08 08:00:00
I have a hobby.
Whenever I see the comment // this should never happen in code, I try to find out the exact conditions under which it could happen.
And in 90% of cases, I find a way to do just that.
More often than not, the developer just hasn’t considered all edge cases or future code changes.
In fact, the reason why I like this comment so much is that it often marks the exact spot where strong guarantees fall apart. Often, violating implicit invariants that aren’t enforced by the compiler are the root cause.
Yes, the compiler prevents memory safety issues, and the standard library is best-in-class. But even the standard library has its warts and bugs in business logic can still happen.
All we can work with are hard-learned patterns to write more defensive Rust code, learned throughout years of shipping Rust code to production. I’m not talking about design patterns here, but rather small idioms, which are rarely documented, but make a big difference in the overall code quality.
Here’s some innocent-looking code:
if !matching_users.is_empty
What if you refactor it and forget to keep the is_empty() check?
The problem is that the vector indexing is decoupled from checking the length.
So matching_users[0] can panic at runtime if the vector is empty.
Checking the length and indexing are two separate operations, which can be changed independently. That’s our first implicit invariant that’s not enforced by the compiler.
If we use slice pattern matching instead, we’ll only get access to the element if the correct match arm is executed.
match matching_users.as_slice
Note how this automatically uncovered one more edge case: what if the list is empty? We hadn’t explicitly considered this case before. The compiler-enforced pattern matching requires us to think about all possible states! This is a common pattern in all robust Rust code: putting the compiler in charge of enforcing invariants.
DefaultWhen initializing an object with many fields, it’s tempting to use ..Default::default() to fill in the rest.
In practice, this is a common source of bugs.
You might forget to explicitly set a new field later when you add it to the struct (thus using the default value instead, which might not be what you want), or you might not be aware of all the fields that are being set to default values.
Instead of this:
let foo = Foo ;
Do this:
let foo = Foo ;
Yes, it’s slightly more verbose, but what you gain is that the compiler will force you to handle all fields explicitly.
Now when you add a new field to Foo, the compiler will remind you to set it here as well and reflect on which value makes sense.
If you still prefer to use Default but don’t want to lose compiler checks, you can also destructure the default instance:
let Foo = default;
This way, you get all the default values assigned to local variables and you can still override what you need:
let foo = Foo ;
This pattern gives you the best of both worlds:
Completely destructuring a struct into its components can also be a defensive strategy for API adherence. For example, let’s say you’re building a pizza ordering system and have an order type like this:
For your order tracking system, you want to compare orders based on what’s actually on the pizza - the size, toppings, and crust_type. The ordered_at timestamp shouldn’t affect whether two orders are considered the same.
Here’s the problem with the obvious approach:
Now imagine your team adds a field for customization options:
Your PartialEq implementation still compiles, but is it correct?
Should extra_cheese be part of the equality check?
Probably yes - a pizza with extra cheese is a different order!
But you’ll never know because the compiler won’t remind you to think about it.
Here’s the defensive approach using destructuring:
Now when someone adds the extra_cheese field, this code won’t compile anymore.
The compiler forces you to decide: should extra_cheese be included in the comparison or explicitly ignored with extra_cheese: _?
This pattern works for any trait implementation where you need to handle struct fields: Hash, Debug, Clone, etc.
It’s especially valuable in codebases where structs evolve frequently as requirements change.
From Impls That Are Really TryFromSometimes there’s no conversion that will work 100% of the time.
That’s fine.
When that’s the case, resist the temptation to offer a From implementation out of habit; use TryFrom instead.
Here’s an example of TryFrom in disguise:
The unwrap_or_else is a hint that this conversion can fail in some way.
We set a default value instead, but is it really the right thing to do for all callers?
This should be a TryFrom implementation instead, making the fallible nature explicit.
We fail fast instead of continuing with a potentially flawed business logic.
It’s tempting to use match in combination with a catch-all pattern like _ => {}, but this can haunt you later.
The problem is that you might forget to handle a new case that was added later.
Instead of:
match self
Use:
match self
By spelling out all variants explicitly, the compiler will warn you when a new variant is added, forcing you to handle it. Another case of putting the compiler to work.
If the code for two variants is the same, you can group them:
match self
_ Placeholders for Unused VariablesUsing _ as a placeholder for unused variables can lead to confusion.
For example, you might get confused about which variable was skipped.
That’s especially true for boolean flags:
match self
In the above example, it’s not clear which variables were skipped and why. Better to use descriptive names for the variables that are not used:
match self
Even if you don’t use the variables, it’s clear what they represent and the code becomes more readable and easier to review without inline type hints.
If you only want your data to be mutable temporarily, make that explicit.
let mut data = get_vec;
data.sort;
let data = data; // Shadow to make immutable
// Here `data` is immutable.
This pattern is often called “temporary mutability” and helps prevent accidental modifications after initialization. See the Rust unofficial patterns book for more details.
You can go one step further and do the initialization part in a scope block:
let data = ;
// Here `data` is immutable
This way, the mutable variable is confined to the inner scope, making it clear that it’s only used for initialization. In case you use any temporary variables during initialization, they won’t leak into the outer scope. In our case above, there were none, but imagine if we had a temporary vector to hold intermediate results:
let data = ;
Here, temp is only accessible within the inner scope, which prevents it from accidental use later on.
This is especially useful when you have multiple temporary variables during initialization that you don’t want accessible in the rest of the function. The scope makes it crystal clear that these variables are only meant for initialization.
Tip for libraries
The following pattern is only truly helpful for libraries and APIs that need to be robust against future changes. In such a case, you want to ensure that all instances of a type are created through a constructor function that enforces validation logic. Because without that, future refactorings can easily lead to invalid states.
For application code, it’s probably best to keep things simple. You typically have all the call sites under control and can ensure that validation logic is always called.
Let’s say you have a simple type like the following:
Now you want to add validation logic to ensure invalid states are never created.
One pattern is to return a Result from the constructor:
But nothing stops someone from bypassing your validation by creating an instance directly:
let s = S ;
This should not be possible! It is our implicit invariant that’s not enforced by the compiler: the validation logic is decoupled from struct construction. These are two separate operations, which can be changed independently and the compiler won’t complain.
To force external code to go through your constructor, add a private field:
Now code outside your module cannot construct S directly because it cannot access the _private field.
The compiler enforces that all construction must go through your new() method, which includes your validation logic!
Why the underscore in _private?
Note that the underscore prefix is just a naming convention to indicate the field is intentionally unused; it’s the lack of pub that makes it private and prevents external construction.
For libraries that need to evolve over time, you can also use the #[non_exhaustive] attribute instead:
This has the same effect of preventing construction outside your crate, but also signals to users that you might add more fields in the future. The compiler will prevent them from using struct literal syntax, forcing them to use your constructor.
Should you use #[non_exhaustive] or _private?
There’s a big difference between these two approaches:
#[non_exhaustive] only works across crate boundaries. It prevents construction outside your crate.
_private works at the module boundary. It prevents construction outside the module, but within the same crate.On top of that, some developers find _private: () more explicit about intent: “this struct has a private field that prevents construction.”
With #[non_exhaustive], the primary intent is signaling that fields might be added in the future, and preventing construction is more of a side effect.
But what about code within the same module? With the patterns above, code in the same module can still bypass your validation:
// Still compiles in the same module!
let s = S ;
Rust’s privacy works at the module level, not the type level. Anything in the same module can access private items.
If you need to enforce constructor usage even within your own module, you need a more defensive approach using nested private modules:
// Re-export for public use
pub use S;
Now even code in your outer module cannot construct S directly because Seal is trapped in the private inner module.
Only the new() method, which lives in the same module as Seal, can construct it.
The compiler guarantees that all construction, even internal construction, goes through your validation logic.
You could still access the public fields directly, though.
let s = new.unwrap;
s.field1 = "".to_string; // Still possible to mutate fields directly
To prevent that, you can make the fields private and provide getter methods instead:
Now the only way to create an instance of S is through the new() method, and the only way to access its fields is through the getter methods.
To enforce validation through constructors:
_private: () or use #[non_exhaustive]
The key insight is that by making construction impossible without access to a private type, you turn your validation logic from a convention into a guarantee enforced by the compiler. So let’s put that compiler to work!
#[must_use] on Important TypesThe #[must_use] attribute is often neglected.
That’s sad, because it’s such a simple yet powerful mechanism to prevent callers from accidentally ignoring important return values.
Now if someone creates a Config but forgets to use it, the compiler will warn them
(even with a custom message!):
let config = new;
// Warning: Configuration must be applied to take effect
config.with_timeout;
// Correct usage:
let config = new
.with_timeout;
apply_config;
This is especially useful for guard types that need to be held for their lifetime and results from operations that must be checked.
The standard library uses this extensively.
For example, Result is marked with #[must_use], which is why you get warnings if you don’t handle errors.
Boolean parameters make code hard to read at the call site and are error-prone. We all know the scenario where we’re sure this will be the last boolean parameter we’ll ever add to a function.
// Too many boolean parameters
// At the call site, what do these booleans mean?
process_data; // What does this do?
It’s impossible to understand what this code does without looking at the function signature. Even worse, it’s easy to accidentally swap the boolean values.
Instead, use enums to make the intent explicit:
// Now the call site is self-documenting
process_data;
This is much more readable and the compiler will catch mistakes if you pass the wrong enum type.
You will notice that the enum variants can be more descriptive than just true or false.
And more often than not, there are more than two meaningful options; especially for programs which grow over time.
For functions with many options, you can configure them using a parameter struct:
// Usage with preset configurations
process_data;
// Or customize for specific needs
process_data;
This approach scales much better as your function evolves. Adding new parameters doesn’t break existing call sites, and you can easily add defaults or make certain fields optional. The preset methods also document common use cases and make it easy to use the right configuration for different scenarios.
Rust is often criticized for not having named parameters, but using a parameter struct is arguably even better for larger functions with many options.
Many of these patterns can be enforced automatically using Clippy lints. Here are the most relevant ones:
| Lint | Description |
|---|---|
clippy::indexing_slicing |
Prevents direct indexing into slices and vectors |
clippy::fallible_impl_from |
Warns about From implementations that can panic and should be TryFrom instead. |
clippy::wildcard_enum_match_arm |
Disallows wildcard _ patterns. |
clippy::unneeded_field_pattern |
Identifies when you’re ignoring too many struct fields with .. unnecessarily. |
clippy::fn_params_excessive_bools |
Warns when a function has too many boolean parameters (4 or more by default). |
clippy::must_use_candidate |
Suggests adding #[must_use] to types that are good candidates for it. |
You can enable these in your project by adding them at the top of your crate, e.g.
Or in your Cargo.toml:
[]
= "deny"
= "deny"
= "deny"
= "deny"
= "deny"
= "deny"
Defensive programming in Rust is about leveraging the type system and compiler to catch bugs before they happen. By following these patterns, you can:
It’s a skill that doesn’t come naturally and it’s not covered in most Rust books, but knowing these patterns can make the difference between code that works but is brittle, and code that is robust and maintainable for years to come.
Remember: if you find yourself writing // this should never happen, take a step back and ask how the compiler could enforce that invariant for you instead.
The best bug is the one that never compiles in the first place.
2025-10-30 08:00:00
How do you build a system that handles 90 million requests per second? That’s the scale that Cloudflare operates at, processing roughly 25% of all internet traffic through their global network of 330+ edge locations.
In this episode, we talk to Kevin Guthrie and Edward Wang from Cloudflare about Pingora, their open-source Rust-based proxy that replaced nginx across their entire infrastructure. We’ll find out why they chose Rust for mission-critical systems handling such massive scale, the technical challenges of replacing battle-tested infrastructure, and the lessons learned from “oxidizing” one of the internet’s largest networks.
CodeCrafters helps you become proficient in Rust by building real-world, production-grade projects. Learn hands-on by creating your own shell, HTTP server, Redis, Kafka, Git, SQLite, or DNS service from scratch.
Start for free today and enjoy 40% off any paid plan by using this link.
Cloudflare is a global network designed to make everything you connect to the Internet secure, private, fast, and reliable. Their network spans 330+ cities worldwide and handles approximately 25% of all internet traffic. Cloudflare provides a range of services including DDoS protection, CDN, DNS, and serverless computing—all built on infrastructure that processes billions of requests every day.
Kevin Guthrie is a Software Architect and Principal Distributed Systems Engineer at Cloudflare working on Pingora and the production services built upon it. He specializes in performance optimization at scale. Kevin has deep expertise in building high-performance systems and has contributed to open-source projects that power critical internet infrastructure.
Edward Wang is a Systems Engineer at Cloudflare who has been instrumental in developing Pingora, Cloudflare’s Rust-based HTTP proxy framework. He co-authored the announcement of Pingora’s open source release. Edward’s work focuses on performance optimization, security, and building developer-friendly APIs for network programming.
2025-10-16 08:00:00
Building autonomous robots that operate safely in the real world is one of the most challenging engineering problems today. When those robots carry sharp blades and work around people, the margin for error is razor-thin.
In this episode, we talk to Andrew Tinka from Scythe Robotics about how they use Rust to build autonomous electric mowers for commercial landscaping. We discuss the unique challenges of robotics software, why Rust is an ideal choice for cutting-edge safety-critical systems, and what it takes to keep autonomous machines running smoothly in the field.
CodeCrafters helps you become proficient in Rust by building real-world, production-grade projects. Learn hands-on by creating your own shell, HTTP server, Redis, Kafka, Git, SQLite, or DNS service from scratch.
Start for free today and enjoy 40% off any paid plan by using this link.
Scythe Robotics is building autonomous electric mowers for commercial landscaping. Their machines combine advanced sensors, computer vision, and sophisticated path planning to autonomously trim large outdoor spaces while ensuring safety around people and obstacles. By leveraging Rust throughout their software stack, Scythe achieves the reliability and safety guarantees required for autonomous systems breaking new ground in uncontrolled environments. The company is headquartered in Colorado and is reshaping how commercial properties are maintained.
Andrew is the Director of Software Engineering at Scythe Robotics, where he drives the development of autonomous systems that power their robotic mowers. He specializes in planning and control for large fleets of mobile robots, with over a decade of experience in multi-agent planning technologies that helped pave the way at Amazon Robotics. Andrew has cultivated deep expertise in building safety-critical software for real-world robotics applications and is passionate about using Rust to create reliable, performant systems. His work covers everything from low-level embedded systems to high-level planning algorithms.
{..Default::default} when creating structs - The alternative is to initialize each field explicitly