Rails originator roasted over Rust boosterism
Ruby on Rails creator David Heinemeier Hansson published benchmarks comparing AI-rewritten versions of his Campfire chat application in Rust, Go and Elixir against the original Ruby implementation. The post, viewed over 900,000 times, appeared to validate both Rust's performance advantages and the utility of AI agents in software development, drawing considerable attention in the programming community.
In the test, the Rust implementation handled 36,260 requests per second on a room page task, vastly exceeding Ruby on Rails (241 requests), Elixir (722 requests), and Go (3,860 requests). However, observers—particularly advocates of competing languages—quickly questioned the fairness of the benchmark, suggesting DHH had optimised the Rust code whilst leaving the others unoptimised. Elixir developers subsequently rewrote their version to achieve comparable performance, casting doubt on the original test's methodology and conclusions.
- DHH's benchmark showed Rust vastly outperforming Ruby, Elixir and Go in speed tests.
- Critics alleged the Rust code was optimised whilst others were not, undermining results.
- Elixir developers rewrote code to achieve similar performance to Rust.
New here? Start with this
David Heinemeier Hansson, who created Ruby on Rails—a popular framework for building web applications—recently published performance tests comparing different programming languages. The tests showed that versions of his Campfire chat application written in Rust, Go, and Elixir performed dramatically differently, sparking considerable debate within the software development community.
The benchmark results revealed Rust handling roughly 150 times more requests per second than Ruby on Rails, with Go and Elixir achieving middling results. However, observers questioned whether the test was fair, suggesting that the Rust code had been highly optimised whilst the other versions had not, making a true comparison impossible. When Elixir developers optimised their own version, they achieved performance comparable to Rust, undermining the original test's conclusions.
Performance benchmarks matter because they influence which tools and languages developers choose, and fair testing methodology is essential for meaningful comparisons. The incident highlights how subtle choices in how code is written can dramatically affect results, and raises questions about how to evaluate new technologies objectively.
Both sides, in good faith
The strongest fair case each way — we don't pick a winner.
The case for
The benchmark demonstrated legitimate performance characteristics and raised important questions about AI-assisted development across languages. Defenders argue that the exercise was valuable precisely because it exposed how different languages perform in practice and showed what's achievable with modern tools. The significant performance gap reflects real-world implementation patterns and language design philosophies, and the benchmark sparked useful industry conversation about performance tradeoffs and AI code generation capabilities.
The case against
Critics raise a sound methodological objection: fair benchmarking requires testing implementations at equivalent optimisation levels. When Elixir developers achieved comparable performance through optimisation, it revealed that the original results conflated implementation quality with language capability rather than isolating genuine performance differences. This undermines the central conclusions about Rust's superiority and AI agents' utility, as the benchmark appears to have compared an optimised implementation against unoptimised alternatives rather than controlling for effort and attention expended on each language.