Yeah, there were various events that basically nullified the considerable traction that Smalltalk had in the 80s and early 90s. And yet, after almost 50 years, Smalltalk still has features not found anywhere.
The awesome development experience aside, just consider containers: One of the main pain points is how to debug them [1]. If getting a stack trace and showing some code alongside it is such an achievement, just consider how cool it is to just snapshot your image when a failure occurs and load that as a running thing, with all the context and behavior still live – while also allowing you to make code changes right while you have an interactive debugger pointing at your issue.
Yeah, there were various events that basically nullified the considerable traction that Smalltalk had in the 80s and early 90s. And yet, after almost 50 years, Smalltalk still has features not found anywhere.
The awesome development experience aside, just consider containers: One of the main pain points is how to debug them [1]. If getting a stack trace and showing some code alongside it is such an achievement, just consider how cool it is to just snapshot your image when a failure occurs and load that as a running thing, with all the context and behavior still live – while also allowing you to make code changes right while you have an interactive debugger pointing at your issue.
[1] https://youtu.be/AdMqCUhvRz8?t=1758
fork() followed by abort() isn’t the same as what you described, but it’s a neat trick for C programs to get a debuggable core file and keep running.
Having the process call gcore will take longer but also not lose the contents of other threads’ registers?
Not a bad idea, though this relies on having gcore (gdb) installed.