Totally agree. I didn’t want to muddy the waters any further by debating the other topic voiced in this thread, but yeah - in the real world of commercial software development, being able to switch off warnings, especially selectively from legacy code so you can still see warnings for any newly authored code, would be very handy in many scenarios.
smathy
dimitarvp
sodapopcan
Waters are pretty muddied and there is an accepted solution is the second answer, so I think this thread still serves the purpose for others to find the answer and read discussion if they still want to. You can’t really post something like this without these kind of answers, especially when the question was also outright asked early on “why explicitly restrict it?” and the answer is that there is almost no good reason to have any warnings in production. @phewitt did make it clear that the situation he’s in is not his fault, so the discussion could have wrapped up a little earlier probably, ha.
Is this true for Elixir? The very fact that this doesn’t come up very often hints that this isn’t a problem for most people. I could be wrong though. But Elixir’s warnings are incredibly easy to fix if you do them as you go. I don’t buy for a second that someone is working soooooo quickly that they don’t have time to remove an unused variable or or add some parens before they push (that is not directed at you, @phewitt). I was thinking about this more recently and I’ll double down on saying I think we’d be much better served if --warnings-as-errors was the default for MIX_ENV=prod mix compile and those who really know what they are doing can set that to false. We are where we are, though!
There is a third hacky way which is to move all offending modules into packages. Depending on how things are organized, though, this could be an even bigger headache. But if you have clear boundaries it’s an option. #2 is prob best, though.
3
dimitarvp
sodapopcan
Onor.io
smathy
I think you’re right that big smelly codebases happen less in Elixir than in other popular platforms. Probably in part due to the very warnings we’re talking about 
Perhaps you’re right that it’s just not a problem: I can imagine that if there were many voices calling for this then the core team might have accommodated them.
Yeah, and I mean in general Elixir is harder to write smelly code in than many other languages, immutability solves a really large number of problems inherently. I also think the bell curve of the sorts of programmers that Elixir attracts skews more towards the “interested in good practices / doing things properly” end of the spectrum.
I’d still rather errors were errors and warnings were warnings, but definitely would be nice to have a MIX_WARNINGS_AS_ERRORS env var, for any MIX_ENV
2
sodapopcan
Maybe the name should be changed to “development affordances” 
As was pointed out earlier, Go doesn’t provide this option and it’s far bigger than Elixir. Often enough, I end up with unused vars while commenting stuff out during development and I would find it super obnoxious if I wasn’t able to run a test because I had one. But I also don’t think it’s worth catering to anyone shouting that it’s their god-given right to push an unused var to production. I’m thankful Elixir is flexible here though OP wouldn’t be in this predicament if it was as stringent as Go is! (Once again, I’m glad it’s not).
3
smathy
Yeah, I suppose I like tools to be as flexible as possible, even though sometimes that leaves the door open for people to do dumb things with them. I prefer to solve those sorts of problems at an organizational level, rather than with restrictive tools.
0
Onor.io
A thought occurred to me that may explain what’s going on here. If you do a mix deps.compile you’ll see warnings for third party packages. There’s not a lot that can be done about those warnings–they’re third party packages and most of us don’t want to make fixes to our copy of these packages because the next time we upgrade our fix will be gone. I get more than one or two warnings if I do this.
On the other hand, mix compile will not report warnings for third party assemblies–only warnings on our code.
Since the OP mentions thousands of files and thousands of warnings I’m guessing they’re doing mix compile but if they are also doing mix deps.compile as part of an automated build process (or something along those lines) turning it off might cut down the number of warnings displayed FWIW.
0