murdoze
I believe we do not have the right tools yet.
They have incorporated the patch into some QNX 6.5 version, but we had to deliver the product long before they did this.
Never again.
It took me 9 months talking to them about this problem until I managed to reproduce it on just two nodes and half a page of code, and record kernel logs that clearly showed a race condition.
We have received a patched kernel in a few days, and it worked like that for a while. This fix was merged into the official release after almost two years.
After that - only Linux, where we can see and fix stuff. No proprietary code and bureaucracy, no "fast, robust and reliable" operating systems.
Roger Zelazny's Roadmarks, if you stretch it a bit.
Which means, w/o deterministic execution Haskell not suitable for a whole niche, where its safety properties are in a high demand. Which is a pity.
In a ring with a unit.
Still in production, for 20 years now.
We used to have our Forth-like system back in 1994, with a virtualized NEXT point, so we had execute, interpret, compile and two link stages behaviors for each word. This allowed produce making an optimizing linker, which produced very tiny .COM-files. I still have source code for it.
I think this idea can quite easily be taken to the extreme, and allow adding things like - type checking - debugging - SSA IR generation (say, for LLVM optimizer) - lots run-time checks (for tests)
So I believe a Forth system can be made quite safe.
If, of course, what you're telling is true.
Or the lucky bastards are in NATO already, out of your reach?
https://www.youtube.com/watch?v=ZsLlYY50zec (English subtitles)