Why pick Rust in 2026 when Go and Zig already solve the same jobs

I keep getting the same question in DMs, usually from someone who already has a working Go service or a Zig side project that does the thing. Why would you still start a new crate in 2026? The honest version is: often you would not. Go already ships the API. Zig already talks to the hardware without a runtime story. Rust is not a promotion. It is a different set of debts.

I shipped backends for years before I started writing about developer experience, and I have been on teams that picked all three. I have also been on teams that picked Rust because a blog post made them feel late. That is a bad reason in any year. It is a worse reason now, when Go’s toolchain is boring in the best way and Zig is no longer a dare.

This is the decision I actually run, not the one that fits on a sticker.

The jobs are less unique than the fandoms

Most of the work that starts a language argument is not a compiler. It is a worker that reads a queue, a CLI that wraps an API, a small agent on a box, an HTTP service that turns JSON into a database row, a parser in front of something you do not trust. Go does those jobs every day at companies that will still exist on Friday. Zig does the ones that look like C with a better attitude: allocators you can see, no hidden runtime, a build system that is part of the language. Rust does them too. That is the trap. Overlap is not a reason. Overlap is the reason you need a sharper one.

If your sentence is “we need a fast, safe networked service,” you have described half the industry. Go will take that sentence. Rust will take that sentence. You have not decided anything yet.

What Go already took

Go took the job of “a small team needs to ship and operate a service without inventing a culture.” The compiler is fast enough that people do not build personalities around waiting. The standard library is large enough that you can get far before you need a religion. Deployment is a binary. On-call is a stack trace you can read at 2 a.m. without opening a book about traits.

I still default to Go when the product risk is “we might be wrong about the feature,” not “we might corrupt the process.” CRUD with a queue. An internal API. A control plane that will change its mind next quarter. A company whose hiring pool is people who have written Go at the last two jobs. That last one is not cynical. A language you cannot staff is a language that will rot in a repo.

Go’s weaknesses are well known and, in 2026, still the same shape. The type system will not save you from a nil you passed through three layers. Generics helped; they did not make Go into a place I want to encode a subtle invariant. The runtime is a gift until it is the thing you have to explain to a latency budget. I have sat in those meetings. If you do not have the budget, you do not have the meeting. Pick Go and go home.

People who switch from Go to Rust because they are tired of nil are sometimes right. They are also sometimes bored. Boredom is not an incident.

What Zig already took

Zig took a different job, and I wish more Rust threads would admit it. If you are writing something that wants to be C — a codec, a driver-shaped component, a game-adjacent engine piece, a tool that must link into a world that speaks headers — Zig is often the more honest modern choice than “C but we promise to be careful” and sometimes more honest than Rust.

Zig’s comptime is a real advantage for code that has to be specialized without becoming a macro museum. The allocator argument is not aesthetics. When I care which arena dies at the end of a request, I would rather see it than infer it from a type that got too clever. And Zig’s cross-compilation story is the kind of boring that saves a week.

What Zig has not taken, for me, is the “hire a team and leave for six months” job. The ecosystem is younger. The libraries you want may not exist, or they exist as a GitHub repo with a disclaimer. The hiring pool is enthusiasts and systems people, not a campus full of internships. That can be fine. It is not the same as Go’s “we can backfill.” It is also not the same as Rust’s “we can find someone who already lost a year to the borrow checker and came out the other side.”

I pick Zig when the artifact is close to the metal and the team is small and proud of that. I do not pick Zig to replace a Go monolith because a timeline said systems languages are having a moment.

The remaining reasons I still open a crate

Rust wins, for me, when the overlap is a lie: the jobs look the same on a slide and are not the same in the failure mode.

Invariants that have to live in the type system. Not “we use types.” A state machine you do not want to represent as a comment. A value that must not be copied. A lock that must not be held across an await you forgot. Go will let you write the comment. Zig will let you be disciplined. Rust will make the next person trip over the invariant instead of the comment. That is worth it on a protocol, a crypto boundary, a database page cache, a WASM guest you do not fully trust. It is not worth it on a webhook that maps three fields.

A dependency story that is crates, not headers and not “copy this file.” This cuts both ways. Cargo can become a graph you regret. It can also be why a team ships a TLS stack without becoming a TLS team. Go’s modules are fine. Zig’s package story is better than it was and still not the reason I would move a product. If the work is “compose libraries into a safe-enough networked thing,” Rust is still the default I trust more than Zig and more precise than Go.

Fear of the silent C class of bug, without going back to C. This is the unfashionable reason and I will keep saying it. Use-after-free, data races you cannot see, a buffer you thought you moved. Go’s runtime removed a lot of that and introduced a different sloppiness. Zig gives you the footguns with the safety off unless you build the discipline. Rust makes the footguns an argument with the compiler. If the process faces the network or holds other people’s bytes, I still want that argument.

The ecosystem you are joining, not the language you are admiring. Embedded, certain CLI cultures, browser-adjacent WASM, a lot of the infrastructure that already standardized on crates. If the code you must talk to is Rust, you pick Rust. I have watched people rewrite a working Go client to avoid a FFI story. Sometimes that is correct. Sometimes it is a three-month detour around a binding.

What I do not treat as a reason anymore: “we might need the performance later.” Measure. “The industry is moving to Rust.” The industry is moving to whatever still has staff. “AI writes Rust now.” AI writes all three now, and it writes broken Rust with confidence. The compiler will catch some of that. It will not catch the crate the agent added to avoid thinking.

The cost that is not ideological

Rust’s compile-time tax is real, even in 2026. I already spent an article on when that wait is worth paying. Here I only need the comparison: Go will not make you build a personality around CI minutes. Zig compiles like a systems language that wants to be done. If your team’s actual bottleneck is iteration speed on a service that changes weekly, Rust is competing with Go and losing on purpose. Do not talk yourself into losing.

The other cost is fluency. A competent Go engineer is cheap to find and expensive to replace only because of domain knowledge. A competent Rust engineer is rarer, and a competent Zig engineer is a phone call to a friend. If you are a six-person company, “rarer” can mean “we cannot take vacation.” I have seen a Rust service become a single point of staffing. That is a worse outage than a nil pointer.

A boring matrix I actually use

I write three lines on a page. I do not share the page in a channel until I am willing to defend it.

What dies if we are wrong about the types? If the answer is “a customer-facing process” or “the disk,” Rust is in the conversation. If the answer is “we ship a fix in the morning,” Go is ahead. If the answer is “we brick a device,” Zig or Rust, and I want to know which one the firmware world around us already speaks.

Who can change this in six months? If the answer is “any backend hire we can close,” that is Go. If the answer is “the two of us, and we like it that way,” Zig or Rust. If the answer is “a contractor we have not met,” do not pick the language that needs a month of compiler therapy.

What is the artifact? A service: Go unless the failure mode says otherwise. A library other languages will call: the language those callers already expect, or C ABI and then the friendliest author. A tool that is really a program about memory: Zig or Rust, and I pick Zig when I want to see the allocator and Rust when I want the next author to be yelled at by the compiler instead of by production.

You can mix them without a speech

The grown-up 2026 answer is often two languages. A Go control plane and a Rust worker. A Zig codec inside a Go server. A Rust library with a C ABI that Zig or Go can call. Purity is how you compile the admin UI and staff a compiler team you did not intend to hire.

I do not need the whole company to “move to Rust.” I need the dangerous boundary to be in the language that makes the dangerous part tedious to get wrong. The rest can stay in the language that makes the boring part cheap to change.

So why pick Rust

Pick it when the job only looks like Go’s job, and the failure is a class Go will shrug at. Pick it when the job only looks like Zig’s job, and you need a library graph and a hiring story that is larger than a Discord. Pick it when the next stranger to the code should lose to the type system before they lose to production.

Do not pick it because Go is uncool. Go is winning the jobs it already won. Do not pick it because Zig is unfinished. Zig is finished enough for the jobs it is honest about. Rust is still the language I open when I can name the invariant, name the process, and name the person who will still be here when the crate gets ugly.

If you cannot name those three, you already have a language. Use it.