On Oct 2, 2013, at 5:25 PM, Walter Bright <newshou...@digitalmars.com> wrote: > > On 10/2/2013 10:10 AM, Sean Kelly wrote: >>> If there's one notion I'd like to terminate with prejudice, it's the notion >>> that a running program can "recover" from bugs in itself. >> >> I worked on a system whose design was specifically built around trapping and >> recovering from segfaults (great design, and sadly, patented). Things like >> this are one of the primary reasons to use a systems programming language. >> So while I agree in the general sense, I don't think it's appropriate for the >> language to make a hard and fast assertion here. I think we should choose a >> reasonable, safe default, but make it overridable. That's pretty much the >> design philosophy of Druntime. > > D being a systems programming language, you can pursue whatever design you > like with it, including bad designs :-) > > Although I haven't seen the system you describe, I'm very skeptical that it > found the solution to the problem of a program successfully continuing after > it has crashed due to program bugs. I remain firmly convinced that that is an > utterly wrong and doomed approach to the problem of reliability.
It isn't a program bug in this case though. This is essentially an object database that lazily maps in chunks of the data store on demand. The objects are then used directly from mapped memory without any intermediate loading thanks to some dirty tricks played to guarantee vtbl placement in application memory across releases. Ridiculously fast and it allows large databases to be used efficiently. This backs an accounting system used by large trading firms. In any case, my point remains that some features like this can be part of a good design in rare cases. So systems languages shouldn't flat out prevent them, but rather put an "experts only" label on there somewhere.
