Challenges with Rust - HackMD

Our interviews with 70+ developers across all experience levels tell a different story. While beginners struggle with ownership concepts, experts face domain-specific challenges—async complexity for network developers, certification gaps for safety-critical teams, ecosystem maturity issues for embedded developers. Even more concerning, we discovered evidence of "silent attrition"—developers who quietly abandon Rust not because they can't learn it, but because the accumulated friction makes them less productive than they'd like to be. … ### Compilation performance: the universal productivity tax **Every single cohort** we analyzed—from novices to experts, from embedded developers to web developers—cited compilation times as a significant barrier to productivity: > "Java takes about 100 milliseconds, Rust anywhere from 5 seconds to a minute depending on what you changed" -- Distinguished engineer working on backend systems at a large company > "8 to 10s iteration cycle... when you want to tweak the padding on a box" -- GUI development team The impact varies by domain, but the pattern is consistent. CLI tool and GUI developers, who need rapid iteration cycles, are hit hardest. Safety-critical developers with 25-30 minute build times face workflow disruption. Size-constrained embedded developers are forced into optimized builds that take longer to compile and complicate debugging. What's particularly important to note, is that this isn't just about absolute build times; it's about the **development velocity tax** that compounds over time. Long compile times can have strong negative impact on code iteration time. Anything that can reduce this code iteration time - hot reloading, fast debug builds, faster linking - will have an outsized impact on development velocity. Moreover, the compilation performance tax compounds at scale. Individual developers might tolerate 5-10 second builds, but teams with CI/CD pipelines, large codebases, and frequent iterations face exponentially worse impacts. One participant noted 25-30 minute builds that create "wait for 30 minutes before the tool finds out I made a mistake" cycles. ### The borrow checker: first it's sour, then it's sweet The borrow checker is often touted as a "beginner problem", and we found that this is largely true: Novices are most strongly impacted by the borrow checker, but this often extends even into the stage where a developer is *comfortable* writing Rust where they *still* get tripped by the borrow checker sometimes. However, highly-experienced Rust developers basically never cite the borrow checker itself as a frustration for them. > Ownership: The first time I went through the chapter, I was really like, what is this? - Developer learning Rust as a first language > I actually did not understand the borrow checker until I spent a lot of time writing Rust - Executive at a developer tools company ### Async complexity: the "Three Horsemen" problem Multiple participants identified `async` as a pain point. Many people, not just beginners, often choose to completely avoid it, instead focusing on solely on sync Rust. This is because, for many, `async` Rust feels completely different. > My biggest complaint with Rust is async. If we want to use [a tool], we're forced into that model...not just a different language, but a different programming model... … ## How challenges amplify differently across domains While the core challenges are universal, different domains have unique challenges that ultimately must be either adoption blockers or acceptable trade-offs. ### Embedded systems: where every constraint matters Embedded developers face the most constrained environment for resources, which can amplify other challenges like learning. > "if you pull in a crate, you pull in a lot of things and you have no control" -- Embedded systems researcher > "can't use standard collections like hashmaps" -- Embedded software engineer Debug builds become too large for small controllers, forcing developers into optimized builds that complicate debugging. … ### Safety-critical systems: stability vs. innovation tension Safety-critical developers need Rust's memory safety guarantees, but face unique challenges around certification and tooling: > "we don't have the same tools we have to measure its safety criticality as we do in C++ and I think it's a worry point" -- Safety systems engineer > "not a lot of people know Rust not a lot of managers actually trust that this is a technology that's here to stay" -- Safety-critical developer on organizational barriers The tension between Rust's rapid evolution and safety-critical requirements for stability creates adoption barriers even when the technical benefits are clear. … ### GUI development: compile times inhibit iteration speed GUI developers need rapid visual feedback, making compilation times particularly painful: > We've got a UI framework that's just Rust code so when you want to tweak the padding on a box ... it's a pain that we just kind of accept a 10 seconds or more iteration cycle. -- Developer … ## Conclusion (not done yet) Rust's challenges are more nuanced than the conventional "steep learning curve" narrative suggests. They're persistent, evolving, and domain-specific. Most importantly, they compound in ways that can create silent attrition even among developers who successfully learn the language. Understanding these patterns is crucial for Rust's continued growth.