Core dumps are at a completely different layer, so they don't really belong in this comparison. Unless we phase out the traditional conception of an OS process in 10 years, which is extremely doubtful.
Horse feathers. Running a debugger, logging, and printf are all much more effective than core dumps.
A core dump may be the most effective way to debug a program that dumped core when crashing in a way that you can't reproduce, but that's because it's the only way to debug a program that dumped core when crashing in a way that you can't reproduce.
Debugging a C application which has already crashed without debugging/logging is what I meant. Assuming you don't add any specific debugging or exception handling code, in dynamic languages you're guaranteed to get at least a vaguely helpful exception message, and you will get one (for varying definitions of "helpful") sometimes in C++, too, if it did not segfault. You do not get that in C by default.
Sorry for the lack of clarity, my statement was incorrect as written.
If you meant that and didn't state it perfectly, then I was too harsh. A mistaken idea may deserve a sharp reply; an incorrectly stated point does not.
In dynamic languages you get an instant burst of maybe-helpful text. (Instant gratification)
With C coredumps, you get a snapshot of the entire system at the moment it crashed. You can literally walk through everything that wasn't corrupted beyond reading. If the system is, for example, a multiplayer game, you can literally navigate the entire gameworld like a frozen snapshot. This can be very helpful for finding well-hidden bugs.
We're professional developers. It is worth the tiny bit of learning curve in order to get more productivity out of our tools!
You're right, my statement makes no sense given the way I wrote it. Sorry. I clarified in my other reply that I meant "out-of-the-box" debugging and error messages, like what Elm is providing here at compile time.
