It's not that hard: Do not rely on your agent to behave when it comes to security, ever. Do not trust your agent to not access your files. Do not trust your agent to not drop your tables.

Just treat it as untrusted software: sandbox it. It takes some effort, but really, just sandbox it. Always.

They're eating the code. They're eating the algorithms.

Assuming your flash allows XIP (execute in place) so all that memory is available for your lua interpreter data, you should at least be able to run some code, but don't expect to run any heavy full applications on that. I don't know Berry but it sounds like a better fit for the scale of your device.

But sure, why not give it a try: Lua is usually easy to port to whatever platform, so just spin it up and see how it works for you!

All of these products are still alive today, actively supported and making my customers good money.

Some things come very natural to Lua: Lua <=> C interfacing is a breeze, and while some modern languages are still struggling to figure out how to do proper async, Lua has been able to do this for decades. The language itself is minimal and simple but surprisingly powerful - a few smart constructs like coroutines, closures and metatables allow for a lot of different paradigms.

For new projects at this scale, I would still choose Lua + C/C++ as my stack. Over the last few years I have been visiting other ecosystems to see what I'm missing out on (Elixir, Rust, Nim), and while I learned to love all of those, I found none of them as powerful, low-friction and flexible as Lua.

> Work with only 3 files [...] Boot in under 5 seconds [...] Use commands without spaces [...] Run CPU opcodes natively [...] Be real

I have a little PCB here on my desk that runs linux with 2 files: vmlinux and busybox. It boots in about two seconds and yes, it runs CPU opcodes natively.

I'm not sure how being able to use commands without spaces or running in real mode is considered better or worse than the alternatives.

When the number of frequencies/bins grows, it is computationally much cheaper to use the well known FFT algorithm instead, at the price of needing to handle input data by blocks instead of "streaming".

Not sure if I agree with this. A proper designed DSL has the advantage of being much closer to the domain of the problem it is supposed to solve. Your code written in the DSL now might end up as 'hard coded' part of the application, but it likely conveys much more meaning in much less code because it is tailored to the core functionality of the application.