Python is actually widely used in scientific community, guys working on data analysis from CERN LHC are heavily relying on Python + NumPy + SciPy for their work as well.
It's easy to learn and makes data analysis really easy with "batteries included" approach (and costs way less than often problematic and buggy MatLab on Linux).
From that link it seems that Python is used at NASA exclusively in ground-based systems. In contrast, the MicroPython+ESA collaboration is supposedly also looking at using the language in "payloads", ie things that go into space.
It's not like ESA has commissioned them to start work on a python implementation for microcontrollers from scratch. Micropython already exists and works.
There really isn't a best or better choice, everything has pros and cons. MicroPython is really nice in that you can write a C (or even inline assembly) extension to the language easily and get access to the low level hardware. It's very similar to writing a C extension with CPython.
I too wonder why ESA and NASA have chosen Python over JavaScript or Lua? The later has been especially design from the ground up for that task. It probably has to do with that their engineers already know Python and Python has a C API too.
I feel like regardless of how ubiquitous Javascript is, it's honestly an awful choice for embedded applications (no, most embedded applications don't sport some racecar ARM A7/A8/A9/A15, and shouldn't if it's not absolutely necessary); there are excellent reasons C still dominates here, and would likely be replaced with something like Rust instead of JS. Manual memory management is usually a huge plus on lots of embedded platforms, static typing is really important here, and most of the code is rather low level. These concerns are really sort of exacerbated on stuff going up into space, as the chips tend to be lower density designs, and simpler. Forth is an excellent choice here, and Lua if whatever you're running on can spare some extra CPU cycles. I guess it will be interesting to see how things pan out with MicroPython.
I would imagine if you could do anything to improve on what exists today for embedded, it would be to push things like verifiable systems harder, kind of what like Margaret Hamilton was pushing with USL[1].
Perosnally i think there's a niche for higher level languages(maybe python) in the non cost-sensitive embedded genre, for systems where size, determinism, peripherals, and maybe power makes embedded micro-controllers attractive - without aiming at low-cost.
And i would guess that there are plenty of developers doing such work , either in research or small volume products(or maybe even medium volume).
Even if you decide that an extra $X dollars is fine to tack onto the price of whatever it is you're shipping, being as updates are as difficult as they are in the field for an embedded device, I still think I'd rather stick with a statically typed language with good testing and verification tools (granted you can blow your foot off with C too, but there's a lot of talent around here for building safety critical system in C--Javascript not so much). It's not just the upfront cost where something like Javascript has the potential to hurt you here.
what you say does make sense. if you care about reliability ,python isn't that good.
but what would be the ideal reliability solution ? I'm thinking rust + freescale chips and low levels libraries(high quality) + some form of community ,like the mbed for higher level code,but where contributions(in rust) are required good testing support. plus maybe some form of reuse for real-time blocks like xcore/xmos enables.what do you think about that ? what's your ideal solution for reliability?
Unfortunately, Ada isn't a 'cool' language any more, so it's hard to get a new generation of programmers interested in it. Even university programs that should know better are teaching almost exclusively in languages that have no business anywhere near safety critical environments.
Sometimes getting things done is far more important than trying to get them done with the most optimal tool, particularly if choice is somewhat subjective.
Does someone know about what SPARC processors they are talking about? I thought (at least for long-range missions) RAD-hardened PowerPC processors where the way to go.
The linked material in the answer is also higly interesting, including details about the RAD-hardening. As the decision was made in 1991 to use the SPARC architecture, it makes sense that they continued the development of their architecture. It is also good to see that there seems to be VHDL code available to tinker with the core in FPGAs. Thank you for the link :)
The ERC32 + LEON (SPARCv7/8) range of rad hard microprocessors developed under contract from ESA. Non fault tolerant versions of LEON are available as open source VHDL. See www.gaisler.com.
Radhard PowerPC are thing of the past I think. No development since the BAE RAD750?
