Since you mention core dumps, please take some unsolicited feedback from an old C programmer: the post-modern "developer productivity" family of languages' lack of core dumps is a bug, not a feature. You want core dumps. They're the right thing. They let you debug a broken program that has since been restarted, or on a different machine than the crash happened, six months afterwards.
Even if you program in a safe language, you still want assert(), and when that assert fails, you don't want an exception: once the exception has torn down a single frame it's too late, since you lose the precious "can't happen" program state.
Sure, C is a low-level language, but I think the YC consensus insufficiently weights the quality of tools supporting this ecosystem. Debuggers and profilers are indispensable, high-leverage tools for saving developer time, and the hip languages these days have followed perl's lead in just sticking -d and -p flags in the reference implementation and pretending the problem is solved.
"the post-modern "developer productivity" family of languages' lack of core dumps is a bug"
Lisp doesn't dump core, it will drop you in a debugger prompt where you can Frankenstein your programmer to life as you wish. Forget Lisp, Scheme and other languages with full continuations will give you the entire run trace of your program in a video tape, where you rewind and fast-forward as you wish. C is not a language whose control semantics you want to brag about.
But back to Lisp, here how you "dump core" in Common Lisp: write a handler for the error condition and call SAVE-LISP from there. One line of code, left optional to the programmer.
"you still want assert(), and when that assert fails, you don't want an exception"
Yeah, it's called by the exact same name in Common Lisp.
"Debuggers and profilers are indispensable"
My Common Lisp has both a deterministic and an statical profiler. Standard Common Lisp has GC, TRACE, ROOM, DESCRIBE, APROPOS, ED, DISASSEMBLE and TIME among others. Those correspond to malloc/free, gprof, ltrace, man, apropos, vim and objdump; in the friken LANGUAGE :-) Everything is tied together with function called semantics and a memory visible to all; not with brittle "shell" languages and text parsing. The vendor and community extensions will make you weep.
There is really no point of comparing Lisp to C; you should compare Lisp to Unix.
FWIW, I don't consider CL a member of the "developer productivity" gang of languages. In practice, it is much more like a better C than it is like python: you have C's relative poverty of libraries and richness of tools.
Still, I meant what I said.
"Lisp doesn't dump core, it will drop you in a debugger prompt..."
What if the user isn't a developer, but, y'know, a user? On the other side of the country, who doesn't care why your code is broken? Will you fly to their site? Hope they let you ssh in and not restart the application while you personally debug it? Hmm, if only it were possible to somehow serialize the state of the broken program, so that someone else could debug it in a different time and place ;).
Even if you program in a safe language, you still want assert(), and when that assert fails, you don't want an exception: once the exception has torn down a single frame it's too late, since you lose the precious "can't happen" program state.
Sure, C is a low-level language, but I think the YC consensus insufficiently weights the quality of tools supporting this ecosystem. Debuggers and profilers are indispensable, high-leverage tools for saving developer time, and the hip languages these days have followed perl's lead in just sticking -d and -p flags in the reference implementation and pretending the problem is solved.