As a new user, it is way more useful. As an old user, you skip right past it.

Every Python exception tells you

> Traceback (most recent call last):

Which is a similar boilerplate statement. Except less useful to newcomers.

And if you doubt the need for newcomers to understand that stack traces and compiler errors are useful, then take a look at new user questions on StackOverflow - it's incredible how many of them flat out don't include that information. This kind of thing makes it way more likely the user recognises this is something useful, and better than that - makes it way more likely they can apply that information and solve their own problem.

> Besides, isn't a bug exclusively something that breaks at runtime?

I mean, it would be a bug if the type checker hadn't caught it. The runtime distinction seems completely arbitrary when we are talking about tools take take runtime errors and make them impossible.

Technically "we've found a bug" ought to be "we couldn't prove there's no bug of this sort" and it can be grating, in the same way Clippy helpfully popping up was grating, to have the latter announced as the former.

You would think so, but personally when I picked up Elm it was extremely handy, and then faded into the background. I expected it to be annoying as an experienced dev, but I actually appreciated it initially and then it wasn’t annoying or even on my radar: my brain skipped right over it.

Once you’re more experienced with the language, you’re typically using your editor to handle the error checking, so the extra “noise” is ignored in the parsing of it.

Nope, it wouldn't. People get used to useless stacktraces and incomprehnsible warnings filling the screen with rubbish, and dismiss them out of hand.

Elm's and Reason's approach let even the experienced dev get to the root of the problem immediately.