RISC-V via librisc implies a lot of untapped potential. There's C/C++ and a bunch of others usable inside that.

Python/Ruby/Erlang et all still have a lot of horsepower so I'd not discount them yet.

the compile loop still slows down an LLM, so like always it's mostly project dependent.

What you want are the errors a compiler provides for guidance to the LLM, and ideally no compile loop; so if your project supports it python + a linter that is hook'd into the LLM for deterministic firing is a very solid choice for lots of LLM projects.

as to the Electron application : I sort of disagree as far as LLMs are concerned.

Once your program takes care of as many things as Electron does under-the-hood your LOC is going to be fairly large and that metric itself is going to be the main thing that makes the codebase less and less compatible with LLM usage. Generally speaking it's best to stick to really modular non-monolithic codebases and make a best attempt at keeping each modular small and well documented.

Once you get some huge monolith somewhere in the codebase LLMs will start losing themselves in unpacking it and the quality of work will drop elsewhere as context is eaten.