The author did not read the Rust, and an agent rewrote it
Piotr Sarnacki wrote on October 11 that DHH, the creator of Ruby on Rails, set out to rewrite Campfire Once from Rails into Rust. More precisely, an agent did the writing, because DHH cannot stand reading or writing the Rust himself. He later added rewrites in Elixir and Go.
Sarnacki treats this as a sample: a person with a great deal of programming experience used an agent to change the code and did not read the result. His judgment is that if you hope to stop reading code, and stop thinking, any time soon, these rewrites are not encouraging.
[1]
Where the prompt was silent, compatibility was changed
He starts with differences that are not features. Whether to keep backward compatibility, whether latency or throughput matters more, how much memory the system may use under load, and whether losing new-content notifications after a crash is acceptable: these questions often have no single correct answer. If the prompt does not say, the model answers them while implementing what you thought you wanted.
The Rust version does not keep full backward compatibility. The example in the essay is that it drops the CSRF token so caching is easier, and it drops Redis in favor of in-process queues, for example for notifications. The Elixir rewrite stays much closer to the original Rails app. Sarnacki argues that these differences do not come from the language. The model did not keep compatibility because the prompt said to rewrite in Elixir.
The CSRF token here is only a control that was removed. It shows that the old behavior was not kept.
[1]A one-percent delivery rate is not counting the same events
Zach Daniels measured delivery of new-post notifications under heavy load. The Rust version delivered about 1 percent of roughly 6 to 7 thousand notifications. The Elixir version delivered 100 percent of about 1.7 thousand. Sarnacki says this shows that Elixir handles backpressure better, and only while the number of requests has not yet overloaded the system.
Both tests were closed-loop: some number of clients, each sending the next message as soon as the previous response arrives, asking how many requests the system can handle in a fixed amount of time. Rust processed about four times as many requests, so it also had more events to send to clients over a WebSocket. A delivery percentage alone does not line up as a ranking of the two languages.
[1]At a fixed rate, the other side starts to time out
Sarnacki reran the test at a constant arrival rate, using DHH's Rust version and Zach's Elixir version with various fixes. At 100 POSTs per second, Rust clients received about 14 percent of events, with no HTTP errors. Elixir received about 60 percent of events, but about 23 percent of the POSTs timed out. The worst event-delivery latency on the Elixir run was close to 180 seconds. When Rust deliveries lag, clients are disconnected. A browser that reconnects fetches the latest messages, which makes the missed events much less necessary.
He is comparing two experiences: a client reconnecting in the background and fetching what is new, or waiting three minutes for news of one message. One number does not finish the story.
The Rust version uses a broadcast channel with a fixed capacity to send new-message events to connected clients. That capacity was set to 256. If a receiver cannot keep up, it falls behind and gets an error. In Elixir, the process that delivers events has a mailbox with no default limit.
Sarnacki changed that Rust capacity from 256 to 16384. At 100 requests per second, the delivery rate rose from about 14 percent to about 90 percent. He thinks this version is actually worse: failing fast and forcing the client to reconnect is better than handling events extremely slowly. The pMAX event-delivery latency rose from 11 seconds to more than 130 seconds, similar to how Elixir behaved. He thinks that is worse than disconnecting the lagging clients. In his view, even 11 seconds is too long, and if the receiver cannot pass the event faster than that, the event should be dropped.
In the same 100-requests-per-second stress test, the Elixir version reached 1.8GB of memory. The question he leaves is whether it is better to drop some messages or to be killed after running out of memory. Elixir does not automatically fix every concurrency problem. Whichever language you use, you still have to decide what happens on failure. The essay gives no matching numbers for the Go rewrite, so none are added here.
[1]