I have watched Discord sit on Electron for years while the rest of the industry complained about the memory and the process sprawl.

The announcement that the entire desktop client is moving to GPUI, with React Native going away on mobile as well, feels like one of those rare moments where a large product team actually follows through on the architecture they already half-built.

Discord has used Rust since 2018 for infrastructure and voice.

Parts of the current client already lived there. The CTO called the full client rewrite the holy grail.

That language is accurate. Electron was always a pragmatic choice for shipping features fast across platforms.

It also meant every Discord window carried a Chromium instance and the associated cost.

Early numbers from the Discord Phoenix build show roughly 290 MB for two concurrent accounts.

The old client could idle at a gigabyte or more and occasionally climb higher. That gap is the difference between a browser and a native GPU-rendered UI.

GPUI is the interesting part of the decision. It is not Tauri.

There is no system webview for the main interface. The framework renders directly, the same approach Zed uses.

Discord is carrying its own patches and has signaled willingness to upstream what makes sense.

That is the pragmatic engineering move: take a production-proven Rust UI layer, adapt it hard, and keep the door open for the original maintainers.

Mobile keeps native UI shells while sharing the core application logic through Rust. The result is one coherent codebase instead of three separate stacks fighting each other.

I am not naive about the risk.

Full client rewrites of applications this large rarely ship on the first schedule.

Accessibility, security, and the long tail of platform quirks will still demand attention. The team has said those concerns are treated with the same priority as performance. That statement matters more than the RAM numbers.

What I appreciate most is the honesty of the trajectory.

They started with Rust where it made sense, kept the pressure on the remaining Electron surface, and eventually decided the cost of staying was higher than the cost of finishing the migration.

Most companies stop at the first convenient layer. Discord is finishing the job.

When the new client reaches wider testing, the real test will be whether the feel stays identical while the resource profile finally matches a modern native application.

I expect it will. The foundation was already there.

Discord is finally rewriting the client in Rust with GPUI was originally published in Rustaceans on Medium, where people are continuing the conversation by highlighting and responding to this story.

Someone looks at a mature codebase written in C, C++, or even Go, feels the weight of its accumulated sharp edges, and reaches for Rust as the clean slate.

I have felt that pull myself more times than I care to admit. The promise is intoxicating: memory safety without a garbage collector, fearless concurrency, and a compiler that refuses to let certain classes of disaster leave the machine.

If you have spent nights chasing use-after-frees or data races, the idea of starting over in a language that simply will not allow those failures feels like relief.

Yet the decision is rarely as clean as the language’s type system.

A rewrite is not a free upgrade. It is a multi-year commitment disguised as a technical choice.

Feature parity is harder than it looks. Edge cases that the original system handled through years of battle-tested hacks do not magically reappear.

Performance wins that look dramatic in microbenchmarks often shrink once the full workload, the allocation patterns, and the integration surface are taken into account.

Teams discover that the hardest part was never the language but the domain knowledge encoded in the old code, the operational muscle memory, and the quiet assumptions that never made it into documentation.

I have watched rewrites that succeeded because the original system had become an active liability.

I have also watched rewrites that stalled halfway, leaving two incomplete systems and a team that lost momentum.

The difference usually had little to do with Rust itself.

It had everything to do with whether the rewrite was solving a real, measured pain or satisfying an aesthetic preference for modernity.

Rust is excellent at preventing entire categories of bugs.

It is not a substitute for product discipline, careful scoping, or the humility to keep the old system running until the new one is genuinely better.

What keeps me returning to the idea, even after seeing the failures, is the long-term calculus.

Once a system is written in Rust and the team has internalized the ownership model, the cost of future change drops.

Concurrent features become safer to add and refactors stop feeling like Russian roulette.

The language’s constraints start to feel less like friction and more like a form of permanent code review that never sleeps.

That compounding effect simply arrives later than the initial excitement suggests.

So I no longer treat rewrite it in Rust as a slogan.

I treat it as a high-stakes engineering bet that must clear a higher bar than enthusiasm.

The language delivers what it promises.

The question is whether the project, the team, and the timeline can absorb the full cost of making that promise true.

On Rust Rewrites 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

🦀 Rebuild Rust in Milliseconds

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

An AI assistant helped me write this. The ideas, the experience and the final edit are mine.

I had this hunch from reading what people write about Rust and agents: the languages we found too demanding might come back, because we’re no longer the ones paying their price.

That suited me: I started out as an Objective-C developer, and I’ve always kept a soft spot for this neglected language. In 2015, at dotSwift, the first Swift conference in Paris, I watched Daniel Steinberg compare it to French cuisine, as opposed to fast food. The image stuck with me, I still prefer fine dining, and it has become a running joke with our junior developers.

In October 2026, an experiment on Objective-C added weight to that hunch. Fernando Olivares, an iOS developer at 37signals, asked two agents, Claude Opus 5.5 and GPT-6.1 Sol, to build the same chat screen in Swift and in Objective-C, then measured everything on an iPhone 12 and published the code and the results. The agents wrote the Objective-C, and it is the leanest version, on a single measurement pass per version: 35 MB of memory at peak, against 44.5 MB for the best Swift version built with the same framework.

I’m not betting on an Objective-C comeback for all that. But what the experiment shows is serious: an agent effortlessly writes a language we found tedious, and that applies first of all to Rust.

The price of Rust

Rust is the language developers admire most: in the 2026 Stack Overflow survey, 67% of the people who use it want to keep using it, a score no other language reaches. Yet many admire it from a distance. Its compiler rejects anything that isn’t safe, and it takes a long time to stop fighting it.

Objective-C was paid for in lines to type, with brackets everywhere. Rust is paid for in compiler rejections. In both cases, the cost fell on the people writing the code. For years, we chose our languages for their comfort.

What the agent changes

An agent doesn’t get tired. Writing a forty-character method name costs it a few tokens, not its patience. And the Rust compiler’s rejections, which discourage a human, become a free check on its own work.

The first measurements point the same way. When SWE-bench Multilingual launched, a benchmark that asks an agent to fix real issues in nine languages, Rust was the language where the agent succeeded most often, and C or C++ where it succeeded least. In July, a team showed that feeding the Rust compiler’s errors to the model while it writes brings the share of code that doesn’t compile down from 20.7% to 13.1% ( arXiv 2607.13921).

When writing costs almost nothing, what’s left is what the language guarantees. For Rust, that’s memory safety, and the stakes are concrete: at Chromium, around 70% of serious security bugs are memory safety problems.

And projects are already following. A team studied GitHub projects that use coding agents: among those created after August 2025, the share of Rust projects doubles, 10.5% against 5.3% among older ones, while C and C++ decline ( Robbes et al., arXiv 2606.07448). Niko Matsakis, one of Rust’s longtime designers, sees it too: in his words, Rust “happens to be a really good fit for agentic coding”, and he draws ideas from it for evolving the language. I see it from another angle, that of the price of these languages, which has changed hands.

What I see at work

We needed Rust on a specific project: the same calculation had to give exactly the same result in the browser and on our servers. Writing two versions, one in JavaScript and one on the server side, meant accepting that they would eventually drift apart. Rust compiles to both, but it wasn’t part of our stack. We’re very happy with the result and the experience, but let’s be honest: without agents, we wouldn’t have tried.

The same mechanism plays out, more modestly, in our iOS engine. Born in Objective-C in 2011, it was gradually migrated to Swift, because it was getting hard to find developers who master Objective-C. The parts we no longer evolve stayed in their original language, and we can now fix them without depending on whoever on the team can still read it.

Further out: proof languages

Rust isn’t the most demanding language. With Lean or Dafny, you write the program, and also the mathematical proof that it does what you expect. The human price is huge: according to Martin Kleppmann, proving the 8,700 lines of C in the seL4 kernel took 20 person-years and about 200,000 lines of proof. Few people know how to write these proofs, and almost nobody does it for ordinary code.

Kleppmann draws a prediction from it: AI will make formal verification mainstream. His argument is the Rust compiler’s, pushed to the limit: the proof checker rejects any invalid proof and forces the agent to retry, so a made-up proof doesn’t get through.

The numbers partly bear him out. In a study published in September 2025, the models’ success rate on Dafny verification tasks had risen from 68% to 96% in a year. At the same date, they solved only 44% of the problems in Verus, the version of Rust built for proofs, and 27% in Lean. Verus is newer, and models have seen less of it.

What I take from it

The question “which language?” had stopped being asked: we took the most comfortable one, and paid the difference elsewhere, in memory vulnerabilities or in bugs no proof had ruled out. Agents reopen the question. We can once again choose a language for what it guarantees, as long as the model knows it well enough.

Cover photo by Judith Browne on Unsplash.

Mathieu Poli, Head of Frontend Engineering at GoodBarber. I write about frontend engineering, product design and AI.

X: hellomathieup · LinkedIn: hellomathieup

Originally published at https://dev.to on October 27, 2026.

Agents don’t mind the brackets: can AI bring back demanding languages? was originally published in Rustaceans on Medium, where people are continuing the conversation by highlighting and responding to this story.