Five Powerful Rust Capabilities Worth Knowing

There's a particular flavor of developer conversation that makes me want to quietly leave the room: the one where Rust gets described primarily as "that language with a steep learning curve" and not much else. It's technically accurate, the way describing a table saw as "that tool that can remove your fingers" is technically accurate. True, but missing the point.

A recent video from the Let's Get Rusty channel on YouTube runs four and a half minutes and does something more useful than either boosterism or skepticism—it maps five specific capabilities that tend to get overlooked in the usual Rust discourse, which circles endlessly around the borrow checker and memory safety. These five things are worth sitting with, because they reveal something about what the language is actually for and where its design philosophy leads in practice.

DSLs Inside Your Language

The first capability—building domain-specific languages using Rust's macro system—might sound like academic wizardry, but it's closer to pragmatic engineering than it appears.

A DSL is just a small, constrained language for solving a specific problem. HTML is one. SQL is another. What Rust allows, via its macro system, is embedding those kinds of mini-languages directly inside Rust code, with the transformation to valid Rust happening at compile time.

The example in the video is modest: a map! macro that lets you create hash maps using object-literal syntax instead of the more verbose standard library approach. But the principle scales considerably. Rust's macro system is expressive enough that entire embedded query languages, configuration DSLs, and HTML-templating systems have been built on top of it. The Yew framework's html! macro—which lets you write JSX-style markup in Rust—is a real-world example that's seen production use.

What makes this worth noting isn't novelty. Lisps have had hygienic macros forever. It's that Rust's version operates within a language that also gives you zero-cost abstractions and memory safety, which is a combination that opens some interesting doors for systems-level projects that still want expressive syntax.

The OS Is Optional

Bare-metal programming—compiling a binary that runs directly on hardware without an operating system underneath it—is Rust's second underappreciated capability, and this one has genuine community momentum behind it.

The video points to Redox OS as evidence. Redox is an actual operating system being written in Rust, and it's a project that's been quietly progressing for years. The fact that you can write an OS kernel in a language with Rust's safety guarantees is not a small thing: historically, kernel development has meant C, with all the memory hazards that implies.

Beyond OS development, bare-metal Rust has become a serious option for embedded systems and firmware. The embedded-hal project and a growing ecosystem of hardware abstraction crates have made it viable to target microcontrollers and real-time systems in Rust without reaching for C. That's meaningful for a community—firmware developers—that has operated in C's shadow for decades without much competition.

Making Misuse Illegal

The third capability gets into something philosophically interesting: the type state pattern, which the video describes as allowing you to "encode rules into the type system to enforce that APIs are used correctly."

Most APIs trust developers to read the documentation. Call initialize() before execute(). Don't call close() on something that's already been closed. These constraints live in README files and hope.

With Rust's type state pattern, you can make those constraints structural. An object representing a database connection in an Unconnected state literally cannot have a query() method called on it—the compiler won't allow it. Transitioning from Unconnected to Connected happens via a method that consumes the old state (using Rust's ownership system) and returns the new one. You can't accidentally keep using the old state because the compiler will tell you the value has been moved.

As the video notes, "the type state pattern is available in other languages, but it's actually uniquely well suited for Rust for a few reasons"—primarily the absence of default constructors (so you control what state objects start in) and the ownership system (so consumed states stay consumed). In languages without these constraints, the pattern is implementable but leaky; you can work around it. In Rust, the type system becomes a specification that the compiler enforces for free.

This isn't just an academic nicety. For anyone building libraries that other people will use—internal platform teams, open source maintainers—the difference between "documented correctly" and "impossible to misuse" is significant. Bugs from API misuse have a real cost, and moving those bugs from runtime to compile time is exactly what the type system is designed to do.

Talking to the CPU Directly

Inline assembly might be the most niche item on this list for the majority of Rust developers, but it's worth understanding that it exists and why.

Rust's asm! macro allows you to embed assembly instructions directly in your Rust code. The video frames this as useful when you need CPU instructions that can't be reached through Rust or even through C—a narrow case, but a real one. Bootloaders, kernel code, and embedded firmware sometimes require operations at a level that higher-level abstractions don't reach: specific SIMD instructions, precise control over registers, or hardware-specific behaviors that no library wraps.

What's notable here is less the feature itself (C has had inline assembly forever) and more what it represents about Rust's design intentions. The language isn't trying to abstract away the machine—it's trying to let you work with the machine safely wherever possible, and step below that safety layer when you have a legitimate reason. The boundary is explicit and opt-in.

SQL Errors That Never Reach Production

The fifth capability is the one I find myself most curious about from a practical standpoint: SQLx's compile-time SQL query verification.

SQLx is a Rust async SQL library, and one of its features is the ability to check your SQL queries at compile time—not by parsing them syntactically, but by actually connecting to a real database and validating the queries against your actual schema. Misspell a table name, reference a column that doesn't exist, or write a query that returns the wrong types? The compiler tells you before you ship.

The video is accurate that this uses Rust's macro system to pull it off, and that it's opt-in—you can disable it for CI/CD builds where a live database isn't available. SQLx supports saving query metadata to files, so you can validate once against a live database and then use the cached results in environments where a live connection isn't available. It's an unusually practical bit of ergonomics.

The broader point here is about where error detection happens. Every step closer to authorship that you can move an error—from production, to staging, to testing, to compile time—reduces the cost and consequence of that error. Compile-time SQL validation is a meaningful step in that direction, even if it requires some setup overhead.

What runs through all five of these capabilities is a consistent design instinct: make the invalid state unrepresentable, catch errors as early as possible, and give developers access to the machine without taking away structure. That's not a unique ambition in programming language design, but Rust's execution of it is notably coherent—the macro system, ownership model, and type system aren't separate features that happen to coexist, they're tools that reinforce each other.

Whether that coherence is worth the learning investment is a question every developer's situation answers differently. But the answer at least deserves to be based on what the language actually does, not the borrow checker horror stories that tend to dominate the discourse.

By Dev Kapoor, Open Source & Developer Communities Correspondent, Buzzrag