Yah that’s fair about other languages. And you’re probably right that’s what he’s responding to.
How about this at a minimum. Could we all agree that a compile error is of more urgency when compiling than a warning? To Pexians point, the main frustration is the warnings drowning our errors more than the warnings themselves.
I was trying to keep succinct because I’m great at going off for paragraphs, especially on this topics 
But I did mean to say that I wouldn’t see the harm in moving errors below warnings. I have no idea if there is a good reason that they can’t be. Only thing would be that it would be one more thing to implement and support that doesn’t necessarily have a very big reach.
And, again, I don’t know your codebase but I wouldn’t be totally confident that problems aren’t present. In my experience people don’t always trace bugs back to their origin; they often figure out some patch to work around the issue and then move on.
And please don’t misunderstand me; I’m not trying to trivialize the issue of dealing with 7 years of careless code. As I said I used to work on C and C++ where there were literally thousands of warnings in the code. I had to convince the team to let me spend some time either fixing the code (if needed) or using the warning suppression stuff built into the compiler. That’s how I caught that if(x=1) error I mentioned earlier. Yes, it didn’t actually appear to be hurting anything (at least there were no bugs in our bug tracker that I could directly trace to that code) but again there were lots of hacks in the codebase and undoubtedly some of those hacks could have been dealing with the fact that the else codepath was effectively unreachable.
Even if there were no error from that particular code, leaving syntactically dicey code like that–code that works in spite of itself–is a recipe for future problems. What if some junior copies that dicey code somewhere else and now instead of one instance of poor code I’ve got two. Of course no developer ever copies code they don’t understand. ← sarcasm.
I mean unless you convince the core committers to change this you’ll have to come up with some sort of work around anyway. How much faster will it be to come up with a workaround than to just go ahead and deal with what the warning is telling you?
I’ll say also that the fact that Elixir is dynamically typed actually makes me far more inclined to avoid some sort of warning suppression mechanism. We already don’t have the safety backstop that typing gives us (although that’s coming). I don’t know about anyone else but I want every check I can get on my code.
You know actually that’d be something I’d like to see as well. I’m guessing they don’t do that now because they’re showing them in the order they’re found. They’d just need to figure out how to sort warnings to the top but that may be a pretty tough thing to do depending on how the compiler is built.
Just a couple of versions ago it actually did! I probably wouldn’t feel as frustrated if my experience was always like this, but rather our UX suffered from upgrading. I thought before it would short circuit, but I guess it wasn’t actually short circuiting. The errors were at the bottom though.
Anyhow, thx for discussion. I’ll hope that a mystical core dev appears with answers 
.
FWIW, you might add to your message (on the Google Group) that they seem to have changed the order of the messages getting output. That may be an unintentional regression on the part of the compiler folks.
That’s a good point. They may be unaware. I’ll add a reply there when I get back home.
Honestly, I kinda used to want this as well, but I don’t really anymore.
For example, in Go, a build will straight up fail if you have a var declared and not used. This seems nice until you want to make a temporary change to get quick feedback while debugging.
Imagine you have some function like this:
func DoSomething(x int) int {
result := x + 1
y := someResult(x) + 1
result *= (y + x)
return result;
}
and you want to comment out result *= (y + x) and sanity check that result is what you think it is.
func DoSomething(x int) int {
result := x
y := someResult(x) + x
// result *= (y + x)
return result;
}
This now won’t even compile and instead will give you a build failed message with y declared and not used. This ends up being a little bit of annoying friction because you need to go back and edit the line that declares y as well.
So now, I think the ideal could be some combination of
Elixir has already got your back 
We can—and should—use the --warnings-as-errors flag for mix compile when building for release (docs here).
Note to the skeptical as this has come up before: This flag only affects to your code. It won’t fail if any of your deps are emitting warnings. This is because Elixir is awesome
This is one of the dumbest thing I’ve seen being implemented in any compilers. You literally have to comment out lines when doing a refactor to be able to compile the project.
Ya, I was thinking this as I read it but figured I wouldn’t say anything 
It may or may not have prompted my “Elixir is awesome” comment which is something I don’t usually throw in I’ve never used Go before but this seems very frustrating.
Frustrating is a much too good of a word to describe this. This is also applicable to unused modules. Take a look at the workaround:
package main
import (
_ "fmt" // no more error
)
func main() {
i := 1 // no more error
_ = i
}
At first I was thinking that this was something they enforced to overcome some limitations in the compiler, but the more I think about it and their other poor decisions introduced in the language, the more I realize that this was most probably the ego of the language designer.
Ya, super annoying. Elixir has the nice in between of just having “warnings” as dev warnings. I wouldn’t have been mad if --warnings-as-errors was set by default when doing MIX_ENV=prod mix compile. OP likely wouldn’t be in the situation they’re in if that were the case, though of course people could still disable it. Some good sense does need to be left up to the developer, of course.
I’ll be a little more charitable and just say the designers are highly opinionated. Which is a GOOD thing - I’d still rather than compared to a language designed by people who aren’t very opinionated and end up with a language that ends up trying to make everyone happy (and as a result, no one is really happy).
That being said… yeah, I am not in love with that choice. But I will give the creators of Golang a lot more credit.
Consider the use case of a variable name typo. For example, let’s say I’ve got code that has someVariable and somevariable (I’m not sure about Go but I do recall that in C variable names are case sensitive). Now in a small function (which is always a good idea) it may just jump out at you that you’ve typo’d the name.
But having seen some legacy code bases where a 500 line routine would be brief, I can say that having the compiler warn me that I’ve got an unused variable (and hence maybe a typo) is actually a good thing. Should that be carried forward into Go and other newer languages? I’m not sure. But I do believe that’s part of the reason the warning exists in the first place.
Is this change in 1.16.1
- [Kernel.ParallelCompiler] Always log errors at the end of compilation
going to address this issue for you? Just wondering since it seemed like it may be a fix for the problem you’ve got?
EDITED to correct version number! Thanks @dimitarvp for pointing that out!
I was about to post the same reply as @Onor.io but got drowned in work and forgot.
(Also it’s 1.16.1 btw, not 1.6.1)
@Onor.io @dimitarvp thx for bumping this. I guess this doesn’t really answer my question “how can I suppress warnings”, but it does at least address my main reason for wanting to suppress warnings in the first place, so i’ll go ahead and mark dimitarvp as solution because he got the correct version 
.
Too summarize for anyone seeing this thread in future.
TLDR; It seems elixir intentionally does not allow warning suppression by design. So, you cannot suppress warnings within the compiler. There are two “hacky” ways to functionally get the desired behavior.
custom compile elixir yourself removing warning code as proposed by @peixian GitHub - peixian/elixir-no-warn at peixian/v1.16-no-warnings
Pipe compiler output into a second script/program to remove them. Like my coworkers do or as proposed by @Cochonours above.
thx for responses everyone!
If push comes to shove you can always just use your IDE to track errors while completely ignoring the CLI output of the compiler. I use NeoVim’s trouble.nvim, it helps a lot to aggregate all problems into a single pane (warnings included BUT they can be turned off with a setting if memory serves). I am pretty sure VSCode has the same.
(Deleted my post since it only seems to have hurt rather than helped the discussion)
© Copyright Elixir Forum | Terms | Privacy & Cookies
