I really didn't mean to make this about Zig vs Rust. That was a mistake. My real point is that Zig is also a great language, even when you care about safety. T

I really didn't mean to make this about Zig vs Rust. That was a mistake. My real point is that Zig is also a great language, even when you care about safety. That said, the things you asked about: 1. I suppose you might get away with linting all of shadow_reuse, shadow_same, and shadow_unrelated. Would that sufficiently disable the feature? 2. The biggest problems with overusing `anyhow` to circumvent the language's error system are performance and type safety. Perf is probably fine enough for most applications (though, we _are_ talking about systems programming, and this is yet another way in which allocation-free Rust is hard to actually do), but not being able to match on the returned error makes appropriately handling errors clunkier than it should be, leading to devs instead bubbling things up the call stack even more than normal or "handling" the error by ignoring any context and using some cudgel like killing connections regardless of what the underlying error was. 3. Rice's Theorem is only tangentially related. Your goal, and one that Rust also strives for, is to make it so that changes to the type signature of a function require compatible changes at call sites, which you can often handle syntactically. Rust allows `let _ = foo()` to also silence errors, and where Zig normally allows `_ = foo()` to silence unhandled return values it additionally requires `try`, `catch`, or `return` (or similar control flow). You have options like `_ = foo() catch {}` or `_ = foo() catch @panic("WTF")` if you really do want to silence the error, but you'll never be caught off-guard by an error being added to a function's return type.