4 ms·

Yeah, when a native app crashes, it just dies. Whereas, generally with Common Lisp, I can trap the condition, fix the problem, and keep running. I know what l

by pnathan 15y ago

Yeah, when a native app crashes, it just dies. Whereas, generally with Common Lisp, I can trap the condition, fix the problem, and keep running. I know what languages I'd consider starting grounds for 100% uptime systems (not 5 9s), and languages that segfault and die as part of their usual crash hangling are not among them. (Erlang, Lisp, and Smalltalk would be my shortlist)

bonzoesc 15y ago
Picking nits here, but (limited) crashing (by design) is exactly why Erlang's failure handling is solid. It's like an automotive crumple zone for your application.
- william42 15y ago
  An Erlang crash is of an Erlang process, which is a tiny green-thread with shared-nothing. That's very different from a C program segfaulting.
  - bonzoesc 15y ago
    Not if your application is a bunch of small C programs that monitor each other a la DJB.
Negitivefrags 15y ago
On windows at least, this functionality is all available for native code. On linux the situation is a little harder. I am not aware of edit and continue on that platform. Any kind of crash is catchable. For example, we get minidumps of our windows software uploaded by the crashing process by catching any kind of crash that is possible, and handling it. However, I would argue that you want to crash and dump a core as fast as possible when something unanticipated is happening. Process death should not be a problem in a well designed system!