Not really; the latter is usually followed by "core dumped", and some amount of useful information written to the disk.

No that is simply not true, seg faults provide useful debug info in any potential core dump they provide.

Also, for something as important as an aircraft, I'd prefer to have a developer who knows what a seg fault is writing the code for any aviation equipment over someone who thinks "'undefined' is not a function" is equivalent to a seg fault.

> No that is simply not true, seg faults provide useful debug info in any potential core dump they provide.

I'm not sure I understand this. Can't you get a backtrace out of a JavaScript exception just as well as you can get one out of a segfault? The segfault itself doesn't carry any information other than at best the faulting instruction and the nature of the fault, and you can surely get that out of a JavaScript exception.

Furthermore, a segfault is very often a sign of memory corruption that has already happened, possibly in the stack frames themselves. "undefined is not a function" is not. JS code that crashes with that error is in a much more debuggable state than native code that crashes with a segfault. And you can certainly configure your interpreter to take a coredump on an uncaught JS exception, which will definitely be more debuggable than a coredump post-memory corruption.

(Your personal attack is not an argument.)

Sorry its really not intended to be a personal attack and i regret the wording.

To clarify what I was trying to convey, the issue I personally find is that JS errors often produce difficult to understand descriptions and misleading traces when compared to some alternative languages.

I do believe that there is good work being done to convert these errors into more usable alternatives. Just recently I caught a glimpse of this: https://plus.google.com/+AddyOsmani/posts/DdWkiKsvbA2

Segmentation faults can also be very cryptic, especially in the memory related cases like you suggested, but its likely that any tool would behave in fairly unpredictable ways when it comes to any form of corruption or out of memory scenario.

Sorry again and hopefully that clarifies my thoughts.

Isn't this story just about the entertainment system? I don't think anybody would advocate using node.js for avionics.

Correct, however given that any addition to the plane has the potential to cause unintended conflicts with critical systems (i.e. in the downed Swissair flight 111 example I gave in another comment) I was suggesting that these should still be treated just as seriously.

Don't get me wrong though, I don't think that using JS in a plane is a bad idea. In fact I think the aviation industry is extremely slow moving and it frustrates me, fortunately the experimental category has access to some interesting tools but for certified aircraft you're very restricted in what you can and cannot do to modify the aircraft.

And 'undefined is not a function' provides a full stack trace to the line of code causing the error. In this particular example, both planes crash, so it's not like anyone would say "But at least it crashed because of a seg fault."

Get off your high horse. What a ridiculous and ignorant comment.

Yes you're right they do provide a trace, however the trace can be misleading and difficult to understand. I attempted to clarify my position in the comments above. Sorry for any offence I caused.