Sadly, the modern software technology ( and i daresay the modern software
coders' mindset ) is responsible for the shoddy and error-ridden code i see
almost everywhere.
In software, you either look for the errors yourself and protect
against them by coding, or you let the compiler/runtime find them
(error checking, bounds checking, bad pointers).
We won't even go into good testing methodology, which can take a
substantial fraction of the time it takes to develop the code itself.
I can only partitally follow you. The problem is not the tool. The problem
is the people using it!! The more sophisticated the tool the more ways to
use it wrong. The more automatisation in the tool the more likely that some
fools use it w/o knowing what they do. And in big projects with many people
involved you will have a combination of both...
But I know what you mean with mindset. eg. introducing a garbage
collection... my mindest is that my code produces no garbage! ;-).
Nevertheless high reliability is less a matter of the programming language
than of the SW concept! And of OS.
If the language has no error checking built in, and permits escaping
from every structure there is, then you have more of chance of
generating and not finding errors (and writing structurally bad code),
than if the language has the tools and structure to either enforce
writing good code, or do error checking itself during runtime.
You pay for some of that with increased code size, complexity, and
slower performance.
Compare C against Pascal, for instance.
Anyway I get the feeling you are more concerned about crashes caused by the
OS than caused by your program.
Maybe the correct order to start would be
1) Choose OS (Startup time? Latency? GUI? long term support? supporting
community?)
add hardware support for your processor and/or OS.
2) Define needed supporting functionallity (math, graph, I/O, protocols...)
3) Think about programming language available for 1), able to interface 2)
And the same things that influence the OS support also influence the
language support.
I'm not sure if you have covered all points from 1), yet.
If you talk about process control I would immediately opt for an RT OS. But
since you want to replace an old hardware Debian is very, very likely fast
enough w/o any RT patches -see toyooka_LCJ2014_v10.pdf
<http://events.linuxfoundation.org/sites/events/files/slides/toyooka_LCJ2014_v10.pdf> .
Nevertheless, you should think about RT OS: I would expect that RT OSs are
not only built for low latency but also for highest reliability -but I'm no
expert on that.
An RT OS has a maximum defined time from an event to responding to it.
Nowhere is it defined how much that time is, but that it is a maximum.
FreeRTOS is available for the BBB processor, should you need to
consider it. It also comes in a high reliability version. An RT OS
is no guarantee of reliability, one way or another.
Note that in terms of latency, if you want millisecond responses,
that's one thing. If your application is to log data every 10
seconds, then an RT OS needs to take less than 10 seconds to do all of
its stuff. Clearly not the same thing, but it fits the definition.
Harvey