With this, we can proceed - easily! - to attain something I have long wanted: to replace all Linux userspace with Lua-only tooling. Yes, Lua all the things in userspace.
I know, "why would I do that?", well, because there is a thing I've wanted for 40 years of computing, and that is a very, very powerful computer that only requires me to use one (oh, okay, two or three..) languages.
I grew up in computers that booted directly to a single language (BASIC), and would let you do everything you need in that and only that. Imagine replacing all userspace tooling with a lua implementation. Yes, insane! But imagine the development flow once you get some good stuff ported/ffi'ed! Having the kernel interfaces available now, is just .. candy.
I would love to have this for a Linux distro, even experimental, even just as a toy, to boot directly into a LOAD81[1] interface that has a whole lotta new Lunatik in it .. I could imagine pushing LOAD81 very hard into a new OS paradigm with this. Wow!
One of the main inspirations for Lunatik is the MS Singularity OS [1], which gets rid of kernel/user space division and implements application/process protection by software using programing language resources. The other one is the MIT Exokernel [2], which provides a tiny kernel with almost no abstractions responsible only for safely multiplexing the hardware. Now, imagine a tiny kernel written in C, exposing Lua APIs, responsible mainly for multiplexing HW; and user processes implemented as separate Lua states running on the same address space, protected by language constructs.
I've just glanced at LOAD81 now.. pretty good job! thanks for sharing.. I noted your keyboard event handling (using SDL).. we have something very related to this in Lunatik (at the kernel level, of course) [1]. We've a kinda fun script that uses keyboard event handling to implement a "key locker" using Konami code [2].
The Arcan project[1] has pushed for this for a loooong time and doing some really interesting cutting edge things with it.
Depending on which set of Lua scripts it runs it fills a different role. The first set becomes the display server and window manager. It can then run itself recursively to provide graphical 'apps' (but also X11 ones, Wayland ones, ...).
I run the 'regular' desktop (stacking, tiling, ...) 'durden' right now, but I hope to switch to the more crazy dataflow/zui one (pipeworld[2]) or the VR one (safespaces[3]).
Then it has an additional 'curses like' one for TUIs and CLIs, 'arcan-tui' with a default shell Lash#Cat9[4]. Looking at their recent posts there also seem to be a network story including server-side processing, but I haven't had the time to play with out more than following the examples in the blog so can't say more about that.
EltaninOS[5] is trying to build a distribution around it.
However, giving you a short answer, we use Lua mainly because it's easy both to extend and to embed. It's implemented as an almost "freestanding" C library. Moreover, it has a considerable small footprint (~250 KB) in comparison to other scripting languages (e.g., Python has a few MB). Moreover, Lua has automatic memory management, fully isolated execution states, protected calls, among other features.
Maybe. Debatable. But the point was more that “replace all userspace [and kernelspace] with X” is the raison d'être of many Forths. So many classic Forth systems boot into a Forth environment, extended in Forth by the programmer-user. If that's what he's looking for, there's 55 years of Forth history to delve into.
With this, we can proceed - easily! - to attain something I have long wanted: to replace all Linux userspace with Lua-only tooling. Yes, Lua all the things in userspace.
I know, "why would I do that?", well, because there is a thing I've wanted for 40 years of computing, and that is a very, very powerful computer that only requires me to use one (oh, okay, two or three..) languages.
I grew up in computers that booted directly to a single language (BASIC), and would let you do everything you need in that and only that. Imagine replacing all userspace tooling with a lua implementation. Yes, insane! But imagine the development flow once you get some good stuff ported/ffi'ed! Having the kernel interfaces available now, is just .. candy.
I would love to have this for a Linux distro, even experimental, even just as a toy, to boot directly into a LOAD81[1] interface that has a whole lotta new Lunatik in it .. I could imagine pushing LOAD81 very hard into a new OS paradigm with this. Wow!
[1] = antirez' LOAD81, which I have long thought of as a fun way to build a new userspace front-end: https://github.com/antirez/LOAD81.git