Rust warns you about those things; allows for quicker iteration in development, and gives you a list of things to address when you are ready to polish.
Go eliminates an entire class of bugs with this feature. It doesn't just make them detectable and less likely. It eliminates them. If you don't care about eliminating them then Go's philosophy isn't for you.
But I for one am sold on that philosophy. I'm disciplined enough that in my rust code I ensure all warnings are fixed before I release. But I don't know if everyone else is just as disciplined. For Go code I do. Every library I use in Go has an entire class of bugs that are impossible. That's a useful guarantee in my book.
On a side note why do we as developers tend to prioritize making the act of writing code easier than the far more frequent act of maintaining that code? Optimizing writing you code over reading and maintaining that code long term seems like a case of premature optimization to me. Allowing something like warnings is one of those things that adds overhead to writing code but eliminates overhead over the life of maintaining that code. The gains are higher longer term at the expense of a shorter term pain. And a pain that tooling like goimports can almost completely eliminate in almost all cases.
Different phases of the development process call for different priorities: in early dev, you want reduced friction and quick turn-around time (something that the unsed imports and variables errors in Go infringe upon). Later on, you want maintainability and ensure that things don't randomly break (at this point, those errors become quite desirable). We shouldn't emphasize readers over writers all the time, we should emphasize them when it's the correct time to do so, which I'll admit is the majority of the time.
> Optimizing writing you code over reading and maintaining that code long term seems like a case of premature optimization to me.
That's actually something I've been thinking about quite a bit in the past few weeks :) I think if we were really concerned about readability of code, we would have much better literate programming tools (e.g., better integration with existing dev tools) and our programs would be written with the intent of being read by others. How many times have we felt lost in a foreign code base (or worse, a code base we wrote, but don't remember too well) trying to implement a change and not knowing or understanding some of the design decisions, being unaware of key assumptions, etc. There is a lot more to readability and understandability than having functions without unused locals. (By the way, why is it okay for a function to have unused input parameters?)
(By the way, why is it okay for a function to have
unused input parameters?)
The amount of development time I save by allowing warnings temporarily when testing easily outweighs any benefit to the ecosystem derived from making that warning abort compilation. I was partially responsible for making this a warning instead of a hard error in Rust and this wasn't even close to a tough call. I would be surprised if a single project in the ecosystem has ever benefited from this: projects that care about software quality pay attention to warnings, and those that don't care about this minimum standard of quality are going to be full of so many other bugs that the unused variable/import warning will make no difference.
> Go eliminates an entire class of bugs with this feature. It doesn't just make them detectable and less likely. It eliminates them. If you don't care about eliminating them then Go's philosophy isn't for you.
Go's philosophy is not about eliminating bugs above all else. If it were, then for example zero values wouldn't exist, reading from a nil map would panic, constants would have stronger types, all fields would have to be supplied when initializing structs, init ordering wouldn't be undefined, overflow would trap, errors would be required to be handled, and that's just off the top of my head.