A clear-headed look at what's still missing from Rust error handling, and a crate exploring a solution. 🦀 By Dillon McMahon, author of eros. The problem isn't the ? operator or Result, those are great. The friction is deciding what goes in the error half. You're choosing between: → Typed enums : precise, but requires a new type declaration for every combination of errors → anyhow : convenient, but the compiler can't tell you which errors are possible or whether you've handled them all The insight behind eros: error types should compose as easily as the functions that return them. Instead of declaring a PortError enum wrapping io::Error and ParseIntError, you write: fn load_port(path: &str) -> eros::Result<u16, (io::Error, ParseIntError)> The tuple describes the possible errors. No new enum declaration at the call site. ErrorUnion holds one of the listed types, not all of them. The part that makes this genuinely interesting: handling an error removes it from the type. fn port_or_default(path: &str) -> eros::Result<u16, (ParseIntError,)> { load_port(path).recover::<io::Error, _>(|_| 8080) } The return type now only contains ParseIntError. A caller doesn't need to know an io::Error was ever possible. And when all listed errors are handled: fn forgiving_port(path: &str) -> u16 { load_port(path) .recover::<(io::Error, ParseIntError), _>(|_| 8080) .into_value() // only compiles when all listed errors are removed } .into_value() only compiles when the error set is empty — the compiler checks that all statically listed error types have been accounted for. For code that just needs to propagate, eros::Result<T> without a tuple defaults to AnyError. Precise where callers need to recover, opaque where they don't. Per function, not per library. Worth noting: eros is early-stage with an evolving API. This is an interesting design direction to prototype with, not a drop-in replacement for thiserror or anyhow in production yet. The Zig comparison at the end is worth reading too. 🔗 mcmah309.github.io/posts/the… #RustLang #ErrorHandling #TypeSystems #OpenSource #Programming

DHH just had agents build Campfire in Rust, Go and Elixir, and Ruby was slowest. Here's what you need to know. DHH (@dhh) posted on Oct 5, 2026 that agents implemented and optimized the Campfire web app in Elixir, Go and Rust. The post has 71.5K views. Rust came out on top in the speed tests. He says Ruby is the slowest of the four. He didn't mind that when Ruby paid off in productivity and developer joy. His question is what changes once you're no longer reading the code. The code is in the basecamp/once-campfire repo on GitHub. He added that speed isn't the only factor. Rust has drawbacks like slow compile times. But when agents write the code and validate the output, he says we need to adjust to a new reality. He also called Elixir not in the same league as something as close to the metal as Rust, so he sees no point in it as a Ruby alternative in an agent-led world. The Elixir result is disputed. Zach Daniel says the agent code ran all SQL queries through a single GenServer, awaited with GenServer.call. He calls that a moronic Elixir implementation. Others say Go should have done better, and that a big Go to Rust gap suggests something was done wrong. The wider debate over Rust for agents was already running. On Oct 3, zack (@zack_overflow) said Rust is no longer the de facto best agent language. His reasons are long compile times, which bottleneck him more than model intelligence does, and agents have gotten good at manual memory management. Ryan Dahl says Rust never was the default for agents. He loves Rust, but says application code belongs in JavaScript or TypeScript. Doug Colkitt says he has never regretted Go for agentic coding. Key numbers: - 3 languages tested: Elixir, Go, Rust - Ruby: slowest - DHH's post: 71.5K views - Posted Oct 5, 2026, 1:14 AM The takeaway is that Rust won on speed. Compile times and the benchmark setup are now the main arguments against it.