Revisiting Rust in 2026
How LLMs and coding agents change the dynamics of adopting a new language.
Back in 2022, I wrote this article — which has been viewed nearly 100,000 times, and still gets hundreds of views a month — on the perils of adopting Rust in a startup setting. Since it’s been a few years, I thought it would be worth updating my recommendations from that piece.
Bottom line up front: LLMs have changed the game, in both good and bad ways, in terms of how easily a team can adopt a new language, especially a complex and somewhat immature one like Rust. Some of my recommendations from 2022 have aged well; others have not.
I recently picked up Rust again for a new project, requiring a high level of performance and a high degree of assurance in the correctness of the code. Scarred from my experiences of four years ago, I had my reservations about using Rust, but the alternatives did not look very attractive.
Being able to compile down to a single binary is very useful for this project, since the application will be deployed in resource-constrained settings. Updating the software in the field can also be challenging when classified systems are involved, so having a single binary simplifies this process.
This is a system that requires the kind of performance and memory safety that Rust provides. My only viable alternative for this project would have been C++, but honestly, I don’t trust myself: the complexity of this system (in terms of memory management, concurrency, and so forth) and the number of sharp corners in C++ would inevitably lead to bugs that I would rather not deal with down the road. So, Rust it is.
The good news is that a few important things have changed that make Rust much easier to adopt than it was in 2022. I’ve been able to crank out tens of thousands of lines of Rust, on my own, in record time, feeling far more productive and confident than I did a few years ago. So what changed?
LLMs for the win
The biggest change since 2022 is the rise of LLMs, which obviously did not exist (at least, not in the form we have them now) back in those days. Before LLMs, I had to nag coworkers with endless questions about the right way to do things in Rust — everything from using traits to building REST APIs. My own ability to code in Rust was very much gated by the time and patience of my more knowledgable peers answering all of my annoying questions.
Now, I can simply fire up my favorite LLM coding tool, and, feeling no remorse whatsoever, can spend hours going back and forth, asking all of the dumb questions, and sharing all of my code for context. This is much, much more effective than bugging humans for help. For the most part, modern LLMs do a very good job at guiding Rust newbies like myself, although I have bumped into issues with the models hallucinating library or language features that simply do not exist, or making recommendations that simply don’t work.
Improved IDE support
Projects like rust-analyzer have come a long way since 2022 and getting real-time errors and warnings in the IDE as I write Rust code is tremendously helpful. Back in those days you often had to shell out and manually run cargo build to find out if something you were doing was valid Rust code. No longer.
I am a huge fan of AI-enhanced IDEs like Cursor and Windsurf for coding in languages like Python and Java, but I have not found them to be particularly effective for Rust. (Granted, I am limited somewhat in terms of which of these tools I am able to use at my job, so even if there are better options out there, I don’t have access to all of them.) Windsurf will often suggest gnarly, complex changes to my code that are not viable refactorings given other constraints, and I usually get better results asking ChatGPT for help on more focused questions, rather than just giving it my entire codebase for inspection.
In a team setting, one risk I have found is that Rust newbies can rely too heavily on AI code generation. While an AI tool like Claude Code can crank out working code, it is not always elegant, can can often be highly non-idiomatic. A Rust newcomer won’t know the difference as long as it works and passes the (LLM generated!) tests.
I’ve now asked that folks on the team working on this codebase not use tools like Claude Code to crank out features unless they (a) really know the codebase well and (b) really understand Rust. The risks of introducing slop into a load-bearing system like this are simply too high.
Personally, I am still not fully comfortable setting Claude Code or Windsurf loose on my code and have it build new features from whole cloth. I often find the resulting code does not mesh well with how I prefer to design things, and these tools can end up making changes to my own delicately hand-crafted code that make it hard for me to understand how it works anymore.
Improved libraries and documentation
The quality and completeness of documentation for popular Rust crates has improved a lot since 2022. One of my biggest gripes back then was the confusing or lacking documentation for important libraries, but this seems to rarely be an issue today.
One challenge I often bump into, though, is poor documentation for Rust macros. Macros are a necessary evil in Rust-land, and sometimes they are abused to patch over a bad choice in API or type system design. Unlike a Rust type or function interface, though, the inner workings of a macro are often very difficult to discern without reading the code, and even then it can be a challenge to understand what the hell is going on. It does not help that things like derive macros are usually in different crates than the code they are generating for, so there is a natural disconnect between the macro and the API it is being used to support. Macros tend to be poorly documented as a result.
Another doc failure I often encounter involves crate features. There seems to be no standard way to document what each feature in a crate is used for and when a given feature is required, so it often comes down to trial and error flipping on features until your code compiles.
Finding Rust developers is still hard
I am sure there are more Rust developers out there than there were 4 years ago, but damned if I can find them. The number of job applicants with JavaScript, Python, and C++ still outstrips Rust by orders of magnitude, even when the job posting explicitly calls attention to Rust as a desirable language. Being at a larger company, this is less of a concern, since we have a pretty beefy recruiting pipeline and lots of resources to find good developers — but one should not assume Rust devs are easy to find. The popularity of Rust on Hacker News is not a good indicator of the actual population of Rust developers that seem to be on the job market.
Would I use Rust at an early stage startup?
Probably not.
Even given the improved landscape and tooling, adopting Rust is still a moderate (if not exceptionally strong) headwind for moving quickly, and moving quickly is essential for early startups. Unless your startup is building, say, robots or super-safety-critical embedded systems, Rust is probably not the right answer when iteration velocity matters more than nearly anything else. One should certainly not adopt Rust because, say, your first couple of dev hires are Rust fans.
Not being at a startup, some of the risks and pain points associated with Rust — for this specific project — are worth the investment. I can afford to make this tradeoff since robustness and performance is more important than developer velocity for a company at our stage, but the calculus changes a lot in an early startup setting. Your first customers aren’t going to give a damn what language or framework your code is written in, as long as it gets the job done — and is 10x better than anything else out there. Startups need to be pragmatic, not dogmatic, in this regard.