Point well taken, but I still think that given these two choices (Nasal vs. JavaScript LLVM front-end), you'd pick the one that doesn't sound like you need to get an ENT doctor involved to do any maintenance
(and no, I am certainly not opposed to Nasal)
Actually, I believe that it was even Erik himself who originally came up with an in-sim implementation integrating JavaScript during the early PUI/PSL days (early 2000s), but then Andy/Nasal came around, ~2003 ...
Like you say, Nasal is doing a good job given its purpose - its primary issues are not language related, and concerning the GC it's actually a rather tiny, and self-contained, module. So it would not seem like much of a stretch to generalize the GC interface (a handful of C functions only) to provide a mechanism for tinkering with alternate GC integrations:
http://wiki.flightgear.org/How_the_Nasal_GC_worksThat being said, I don't fully subscribe to the notion that the GC is the actual problem here - many/most scripts don't even need to run in the main loop at all, so that the GC mechanism should not even matter if the whole interpreter/context runs out of the main loop, i.e. if Nasal scripts were to talk to the rest of the sim (main/rendering loop) via message passing primarily.
I totally agree that switching to another language, especially a more popular/established one, is likely going to make such issues even more prominent. Python, Lua and JavaScript are obviously great for a plethora of reasons, but the degree of 3rd party tooling, libs and documentation would also mean that the shortcomings in FlightGear's architecture would become very visible within a few months time.
The whole FGNasal/SGSubsystem-based integration on top of listeners/timers is literally begging for trouble - which is certainly also the main reason for most core developers encouraging people to re-implement their Nasal algorithms via property rules, or rewrite their Nasal code in C++ directly.
We did have the same discussion in the context of bugman's FGPythonSys experiments.
I don't quite see how LLVM is supposed to help with the real issues we're seeing in the FlightGear scripting department - if anything, it means faster Nasal code execution in the VM - but that won't solve the real problem. Like Richard said, dumb code can be written in any language - thus, a Nasal frontend for LLVM would at best create faster Nasal code, that would only hide the real problem better - which is bringing us back to the incidents surrounding the creation of the so called "Effects Factory", due to Torsten's findings that we had native (C++) code doing really dumb things at frame rate.
I am still not quite sure what the goals for a Nasal/LLVM frontend are - but I don't think it's going to have much of a positive impact on FlightGear scripting at all.
Let's just imagine, there'd be a working Nasal/LLVM front-end right now (should be easy enough to prototype), what would be the next step ? What do you think is going to happen realistically ?
Compared to the work that would be involved in fixing the GC or providing support for alternate GC schemes, it seems rather excessive to tinker with a new LLVM frontend.
Don't get me wrong, I do still believe it's an interesting discussion/idea - but I also think it's time for a pain/gain check. For instance, the Nasal GC module is roughly 400 LOC last I checked, and it's really self-contained too. There are meanwhile many 3rd party GC libs available that could be integrated for testing purposes.
Anyway, even that kind of work could be redundant if NEW Nasal scripts could be delegated to dedicated worker threads - which primarily means coming up with a safe versions for accessing simulator internals, via some kind of messaging API (not even talking about HLA/RTI).
My thinking here is that there is an increasing tendency among some folks to go all on on "totally rewrite X", without realizing how much work that comprises (working features vs potential regressions).
From a pain/gain standpoint, coming up with a Nasal/LLVM front-end is certainly going to take much time than integrating other GC schemes, or fixing the built-in one, even if that just means running the GC in a background thread (as per AndersG's patches). Likewise, coming up with a down-stripped version of FGNasalSys that runs its scripts in a background thread that only ever talks to the rest of fgfs via some MPI-like mechanism is going to provide more bang for the buck.