Author's note
The original version of this article has been retracted. I used an LLM to draft the initial text, though only after extensive planning—hours spent analyzing data and identifying key points. I then edited every line to match my voice and verify accuracy. Still, many readers felt the AI-generated tone came through uncomfortably. Given this feedback, the Rust Project and I decided to retract the post entirely.
I stand behind the substance. The LLM didn't choose what to say—I did that work beforehand. I made edits to narrow claims when I couldn't find direct quotes to support them (even when my experience as a Project member suggested they were true). The Vision Doc team defined the content, not the AI.
Some readers found the post "empty" or lacking substance. I understand that reaction, but it reflects both the nature of our data and our methodology. The Vision Doc team conducted roughly 70 interviews, mostly one-on-one. That's substantial data, yet difficult to distill into a single post. It's also insufficient to capture nuanced differences across user segments. Unsurprisingly, the problems surfaced in interviews were largely known issues. The value lies in understanding which problems matter most to whom.
Our insights and conclusions are grounded in collected data. The Vision Doc team has worked to remain neutral, making only claims the data directly supports. With more time, I would have incorporated our ~5,500 survey responses to strengthen conclusions. That time wasn't available, but it shouldn't diminish what we have learned.
Wording matters. The published post clearly missed the mark for many readers. LLMs are tools people use—myself included—to compensate for constraints in skill, time, or motivation. I used one to help process transcripts from 70 interviews and subsequent analyses, given limited time. The three-month editing timeline didn't help; early drafts that worked became problematic in later revisions.
The Vision Doc team owes the Rust Project and community transparency about our findings. So I'm sharing the challenges we identified, with personal commentary rather than formal recommendations. I've excluded specific quotes, focusing on high-level themes. Fair warning: this makes these statements more subjective than our typical Vision Doc publications.
Across 70 interviews, the Vision Doc team heard many complaints. We kept discussions high-level, avoiding technical minutiae. We wanted to understand general difficulties people encounter. Below are common challenges affecting most users, plus some domain-specific issues.
Challenges that are universal
Several issues came up consistently across interviews. Addressing them could have broad impact, though they don't necessarily block Rust adoption.
These universal challenges are familiar. If you write Rust, you've likely hit them. That's what makes them universal. The value in our data is confirmation: we sampled different domains, experience levels, and backgrounds, and found these challenges affect everyone.
Compilation performance
Rust's compile times are notorious. This is a moving target: the Project tracks compiler performance on every merged change, many have attempted improvements, yet there's always more to do.
The good news: no interviewee said compilation time currently blocks them. We heard concerns like "if we keep expanding our Rust codebase, compile times might become an issue eventually." We're not in the clear, but it's important to weigh this against other challenges.
Borrow checking and ownership
Another signature Rust challenge. Nearly every beginner struggles with borrow checking and ownership. However, we found that experienced Rust developers rarely complain about the borrow checker—it's a hurdle that experience overcomes. We can still improve the beginner experience, though the path isn't obvious.
Learning materials and compiler diagnostics help, and we've invested heavily in both. Still, the borrow checker remains difficult. We have ongoing efforts to improve it, and language features might help (or hurt).
We found previously that Rust's strength lies in balancing reliability, efficiency, and versatility. Adjusting something as fundamental as the borrow checker requires preserving that balance.
Async
Async consistently surfaced as problematic. Beginners often ignore it entirely while learning. Users who do adopt async say the decision isn't always clear, and even when it feels right, they still encounter friction.
Unlike performance and the borrow checker, we have concrete next steps for async: async functions in traits, async drop, async versions of standard library traits. These will start addressing issues and closing gaps. For other problems like function coloring, solutions remain elusive.
Ecosystem crates
We previously discussed how crates.io provides tremendous resources while also creating challenges. When crates exist for a given need, users must determine: which crates do what they need, which are trustworthy, and which are best for their use case. In some domains and industries, necessary crates simply don't exist—Rust support remains too immature.
Challenges that are domain-specific
Despite limited diversity in our interview sample, we identified challenges that disproportionately affect certain domains.
Embedded
Embedded developers face difficulties rooted in constrained resource management. They often can't use most crates from the ecosystem, struggle with standard library usage, and face harder debugging experiences. What's routine for typical Rust developers becomes exceptional for embedded work.
Safety-critical
We published an entire post about shipping Rust in safety-critical systems. The primary obstacle: lack of mature tools to certify Rust code.
GUI development
GUI developers cite compilation time as their biggest issue, but with a twist. GUI work depends heavily on visual feedback, creating a different workflow than "compile and run tests." The iteration cycle matters differently here.