Being a fan of modern dynamic interpreted languages like Python and Ruby, I have to agree that compiling them can only be suboptimal. Major reasons are GIL and GC (global interpreter lock and garbage collection, bad news for anything multithreaded, realtime or algorithmically predictable) as well as the dynamic runtime behaviour and dynamic typing of those languages. Any compiled runtime would have to replicate exactly what the interpreters do anyway, or else lose dynamism, ease of use and, ultimately, compatibility to the respective languages’ idioms.
With Ruby, there have been many variants like jRuby (runs on top of Java VM), mruby (subset of Ruby), Rubinius, Truffle Ruby etc etc. But they all have their disadvantages compared to standard Ruby.
Ruby’s »killer apps« (YaST, Rails, Metasploit, Sketchup, Github etc.) and Python’s (Yupiter etc.) illustrate the sweet spots of these languages. It’s certainly not the automotive/embedded/realtime/hardened use case.
“Suboptimal” may still not necessarily mean “preferred.”
If you want or need the predictability and reliability of compiled, then a few sacrifices might be endurable elsewhere, especially given the vast amount of available python code for RPi vs every other language.
It might also be useful or important to understand how the final code is executed and account for those factors when choosing and writing your code… So, for instance it might be useful to know that if you choose Nuitka, that will convert Python to C++ code for execution.
My personal experience in this area (running compiled script code) is limited to a project I did using Iron Python years ago, and running Javascript in V8 today.
The issues you describe compiling to dotNET just don’t exist AFAIK, but that is likely because dotNET is a managed code environment (like Java). Stuff like GIL and GC aren’t at the top of your list in a managed code environment and are looked at only if a problem is noticed (which is rare). Yes, that could be very different with Nuitka which is compiling to unmanaged C++. The main well known disadvantages of dotNET(and Mono) are the very large Frameworks which must be installed on the machine and that when an application is first executed, there is a significant latency issue as the app and data are loaded into memory. But otherwise, I don’t know that anyone typically experiences any kind of problems that aren’t easily addressable running the app.
As for Javascript and the the Google (Chrome) V8 engine, it’s a total unqualified success story. I don’t know of a single story anywhere that regular Javascript created by anything or to any version past or present has a problem running in the V8 compiler (which is a runtime replacement for common JS interpreters). No one running JS ever notices anything different except perhaps the blinding speed if you’re running a <very> big app. And, I never hear anyone mention any problems like GiL and GC running in V8.
V8 is really the example of the future…
Write in a language that’s simplest to learn and world-common (Javascript) and execute as compiled.
Didn’t know about rust (cargo) so I did some checking and yes avail from yast install so I installed it but not impressed. From what I see it’s just a clumbsy wrapper. you make the project folders and directories using command line tools, open an editor like vim to modify the generated files to something using rust syntax and file naming technics. Many of the commands are variants of just typing in ‘C’ and when you think you have a working program try to run it from the command line REAL 1960’s method. It’s not a IDE, not a GIDE but it does remove the complexity of building each and every module independently. So to use it to make a GUI program I still need to write and compile the program using a GIDE as a library and then import the library as an external library. Which can then be referenced from the rust and recompiled into a runable program. Looks like a lot of work for very little return. Sorry for being so candid.
v8 to run javascript is great if you want to develop for the WWW but not for console, GUI, and direct device control apps. No governing authority would allow autonomous vehicles , EV’s or even ICE’s to rely on script languages Yes they allow scripting to be used to the extent of diagnostic information communication and data updates to the underlying engine that drives the systems. But all core systems must be in compiled machine code for intended architecture. That’s why they restricted Visual Studio on MS platforms to exclude VB and on all platforms the use of scripting of any kind.
I got QT5_creator finally working by making changes to the vender repositories stated in an early posting. I was even able to make the objects for the display but for some reason they lack any properties to change the colors of text foreground or background. Seams my choices are white, black, light grey, dark grey. and image. So if I want to show a left turn indicator I have to change a black on grey arrow image to a green arrow on grey image and blink swap them?? Remaining battery level however is a range scale of green level on a bed of grey. Buttons to are grey on grey or black on grey. Admittedly, I only spent 5 minutes making a basic layout. And have no idea yet how I will add the c code to control items from code yet. I just wanted to see if I could replicate the display of intended objects.
A FYI which may be important for anyone who is writing an app like what the @OP describes…
An app where timing is critical, latencies must be eliminated.
I came across the “PREEMPT_RT patch” project,
This is the main project website page which shows that today it’s extremely active and researched https://wiki.linuxfoundation.org/realtime/start
For me, the killer ruby app is actually sinatra, and in building domain specific languages like in vagrant. I have used Ruby for a lot of things, but I never did RoR. There is also Ruby integrated jit now (2.6), which seems a good compromise.