This is really a double-edged sword. We have lots of detections for Perl-isms, for example. However, they drive me up the wall because, for me, 100% of the time they get triggered when I write perfectly valid Rakudo code and the compiler merely assumes (incorrectly) that I tried to write Perl code. Another thing is wall-of-text errors that I've seen people point to already. You can write a novel, explaining everything, but you can't make people read it. > Instead of telling me I am stupid, it should give me > direction to fix the problem. Pointing at the specific paragraph in > the documentation can be part of it. To play the devil's advocate, I want the error to be fewer than 5 words: a location and a hint. I'm competent at Rakudo, so I can easily figure out what part of code is wrong with only that information and the paragraph-length errors just get in my way, trying to parse the crux of the error. This difference of needs and opinions is why IMO core errors should just provide this… checklist… of elements important to an error and then custom exception handlers (something that we already support) can be used to cater actual errors to the proper demographic. Are you new to the language? Set RAKUDO_EXCEPTIONS_HANDLER env var in your system to `NewLearner` and get extensive errors explaining how and why. Do you want your errors to load relevant docs to display alongside the error? Set RAKUDO_EXCEPTIONS_HANDLER env var in your system to `DocsLoader`. Do you want your errors to just get straight to the point? Set RAKUDO_EXCEPTIONS_HANDLER env var in your system to `Terse`. You can't just claim that users who are new to the language and who don't want to read the docs are the demographic we're supposed to target with our errors, because then you leave out a huge swath of other programmers who don't want their terminals spammed with information they're not interested in.