> Often, the bug is caused by an accidental use of := instead of =.

This is a distinctly Go problem, not a problem with shadowing as a concept. In Rust you'd have to accidentally add a whole `let` keyword, which is a lot harder to do or to miss when you're scanning through a block.

There are lots of good explanations in this subthread for why shadowing as a concept is great. It sounds like Go's syntax choices make it bad there.

> There are lots of good explanations in this subthread for why shadowing as a concept is great

Not really. All of them boil down to ergonomics, when in reality it doesn't bring a lot of benefit other than people hating on more descriptive variable names (which is fair).

You're saying ergonomics aren't a good explanation? The entire point of a programming language over writing machine code boils down to ergonomics! You've got to do better than "it's just ergonomics" when your argument for a language to ban shadowing is also "just ergonomics".

The debate here is about which one truly has better ergonomics!

You can (assuming you're talking about Rust)! Just use Clippy and add #[deny(clippy::shadow_reuse)]: https://rust-lang.github.io/rust-clippy/master/#shadow_reuse

My position on shadowing is that it's a thing where different projects can have different opinions, and that's fine. There are good arguments for allowing shadowing, and there are good arguments for disallowing it.

This is another big difference between Rust and Zig. Rust lets you have it both ways with configuration. Zig places much more value on being able to read and understand any Zig code in the wild, based only on “it compiles”. Rust’s “it compiles” gives you lots of information about safety (modulo unsafe blocks), but very little about certain other things until you’ve examined the 4-5 places which might be tweaking configuration (#[attributes], various toml files, environment variables, command line flags).