they're focused on risk-reduction and would prefer all production software to be written in Java. - this is cancer, so to speak.)
I know only one way to reduce a risk of running a software - choice an appropriate hardware, and run as less software as possible.
You must know your hardware and your software. That means it must be compact, readable and easily modifiable, so that you can quickly adapt and fix it, on the go.
So, I would choose a well-defined, mostly-functional, small, simple language, with decent compiler directly to native machine code and very thin FFI, to use specialized OS services.
It could be a solution from http://scheme.com or Gambit-C, not anything that begins with J.
So, in my opinion, a native compiler for, say, Arc to x86_64 (written in Lisp) with UNIX integration (NO Windows support) would be a better solution. Unfortunately, it doesn't exist yet.)
It seems like Go is taking the same approach - they have very thin layer of abstraction on top of an OS (post of Plan9 core libs) they have native compilers, and comprehensible runtime. So, this is real, available better solution.
There is Erlang - almost the same underlying principles, but complicated with a VM.
In order to reduce risks you must have deep understanding of what you are running.
I'm loving Go, it doesn't have a lot of libraries designed for Machine Learning, but it's easy to write wrappers and we have one for Bayesian operations: https://github.com/jbrukh/bayesian
I'm investing my time in learning this language: I'm sure it will be more widely used in the following years.
I know only one way to reduce a risk of running a software - choice an appropriate hardware, and run as less software as possible.
You must know your hardware and your software. That means it must be compact, readable and easily modifiable, so that you can quickly adapt and fix it, on the go.
So, I would choose a well-defined, mostly-functional, small, simple language, with decent compiler directly to native machine code and very thin FFI, to use specialized OS services.
It could be a solution from http://scheme.com or Gambit-C, not anything that begins with J.
So, in my opinion, a native compiler for, say, Arc to x86_64 (written in Lisp) with UNIX integration (NO Windows support) would be a better solution. Unfortunately, it doesn't exist yet.)
It seems like Go is taking the same approach - they have very thin layer of abstraction on top of an OS (post of Plan9 core libs) they have native compilers, and comprehensible runtime. So, this is real, available better solution.
There is Erlang - almost the same underlying principles, but complicated with a VM.
In order to reduce risks you must have deep understanding of what you are running.