{"id":472,"date":"2026-07-17T13:04:21","date_gmt":"2026-07-17T13:04:21","guid":{"rendered":"https:\/\/abrarqasim.com\/blog\/rust-macros-2026-when-macro-rules-earns-its-place\/"},"modified":"2026-07-17T13:04:21","modified_gmt":"2026-07-17T13:04:21","slug":"rust-macros-2026-when-macro-rules-earns-its-place","status":"publish","type":"post","link":"https:\/\/abrarqasim.com\/blog\/rust-macros-2026-when-macro-rules-earns-its-place\/","title":{"rendered":"Rust Macros: When macro_rules! Earns Its Place (And When It Doesn’t)"},"content":{"rendered":"

I put off learning Rust macros for about a year. Every time I hit code that obviously wanted a macro, I’d shrug, copy-paste the thing a few more times, and promise myself I’d learn the macro system “properly” later. Later never showed up. What finally broke me was a match<\/code> block I’d rewritten so many times my git blame looked like it had a stutter.<\/p>\n

So I gave up a weekend and actually sat with them. Turns out I’d been scared of the wrong half. macro_rules!<\/code>, the declarative kind, is far friendlier than its reputation. The genuinely gnarly part, procedural macros, I reach for maybe once a project, if that. This is the guide I wish someone had handed me: what the two kinds are, when each one earns its keep, and the times I’ve regretted writing a macro at all.<\/p>\n

Two kinds of macros, and why the split matters<\/h2>\n

Rust has two macro systems, and beginners (me, a year ago) tend to lump them together and get intimidated by the union of their worst parts.<\/p>\n

The first is declarative macros<\/strong>, written with macro_rules!<\/code>. You pattern-match on syntax and expand into more syntax. Think of it as a very literal find-and-replace that understands Rust’s grammar. Ninety percent of the macros you’ll ever write are this kind, and they live right in your normal source files.<\/p>\n

The second is procedural macros<\/strong>: custom derive<\/code>, attribute macros like #[tokio::main]<\/code>, and function-like macros such as sqlx::query!<\/code>. These run actual Rust code at compile time to generate code. They’re strictly more powerful and strictly more annoying. They need their own crate, they pull in heavy dependencies, and they slow your builds down. The official macros chapter of the Rust book<\/a> lays out the taxonomy if you want the formal version.<\/p>\n

The practical takeaway: you write macro_rules!<\/code>, you consume<\/em> procedural macros other people wrote. Keep those in separate mental buckets and the fear mostly evaporates.<\/p>\n

macro_rules!: the one you’ll actually write<\/h2>\n

Here’s the code that finally sold me. I had a config-building block that looked like this, in a few different places:<\/p>\n

let mut config = HashMap::new();\nconfig.insert("host", "localhost");\nconfig.insert("port", "5432");\nconfig.insert("user", "claude");\nconfig.insert("sslmode", "require");\n<\/code><\/pre>\n
Fine once. Tedious the fourth time. So I wrote a tiny macro:<\/p>\n
macro_rules! map {\n    ($($key:expr => $val:expr),* $(,)?) => {{\n        let mut m = std::collections::HashMap::new();\n        $( m.insert($key, $val); )*\n        m\n    }};\n}\n<\/code><\/pre>\n
And the call site collapses to this:<\/p>\n
let config = map! {\n    "host" => "localhost",\n    "port" => "5432",\n    "user" => "claude",\n    "sslmode" => "require",\n};\n<\/code><\/pre>\n
Three things are worth unpacking, because they’re most of what you need to read any macro_rules!<\/code> in the wild:<\/p>\n