I ask this question, but instead: I ask it of Lua.
As in, what if there was a Linux distro that focused, primarily, on building a Lua layer on top of everything, system-wise. Just replace all the standard stuff with one single, system-friendly language: Lua. C/C++ everything as it currently is: put Lua on top all the way to the Desktop.
It’s only a thought experiment, except there are cases where I can see a way to use it, and in fact have done it, only not to the desktop, such as of course embedded. Realtime data collection, processing and management. In this case, it is superlative to have a single system/app language on top of C/C++.
So I think there may be a point in the future where this ‘single language for everything’ becomes a mantra in distro land. I see the immense benefit.
Lua table state can be easily transferred, give or take a bit of resource management vis a vis sync’ing state and restoring it appropriately. Lua Bytecode, itself, in a properly defined manner can serve as a perfectly cromulant wire spec. Do it properly and nobody will ever know it isn’t just a plain ol’ C struct on an event handler, one of the fastest, except it’ll be very well abstracted to the application.
Oh, and if things are doing bytecode, may as well have playback and transactions intrinsically… it is all, after all, just a stream.
App state as gstreamer plugin? Within grasp, imho…
There used to be a roguelike game called Angband, which was written in C. There was a vibrant community around it, many of whom produced Angband variants by hacking the text config files and the C code. One developer got the idea of making most of the game scriptable in Lua, over a C core; which would, in theory, make even more people be able to hack at the game and produce variants.
What happened was the Angband community imploded, and the number of variants went way down.
I don't know if this is a generalizable example and there may have been other factors at work, but it is a cautionary tale.
Angband is still around btw, and is still excellent. But I believe it's C and text config files again now.
When I was a wet behind the ears programmer, I learned a cautionary tale about Lisp and macros. Very smart people love macros and are good at them, and will modify things to fit their needs. Problem is, other people think different ways. A flexible language which is easy to mutate results in incompatible dialects.
The sage elders suggested that making the language harder to change (cough Python) is more likely to result in a single widely used dialect, with the differences at the library level rather than in language/macro level.
Wouldn't you face the same problem as Dotnet on Windows? AFAIK, dotnet based frameworks and apps suffered from huge performance issues. It might have improved in recent times, I am not actually a windows dev.
If just the end user application is in Lua, then maybe it's fine and the high level language slowdown won't matter. If you want to wrap the low level kernel APIs etc in a high level language as the canonical interface, I would be very skeptical.
I’m not sure the ‘language slowdown’ is as significant as one might think, given the common shared libs that would be in place with a one-size-fits-all solution, but its really all just a dream until someone does it, anyway.
Dotnet is pretty fast these days. It has a lot more low level control than something like Java, with value types and manual memory management available (it invented the unsafe{} blocks Rust is famous for).
MS even had a prototype version of Windows where the entire OS from the kernel up was managed code (a little excessive, IMO).
Dotnet GUI apps failed on Windows mostly because their UI toolkits are a mess and Electron won the cross platform war. I avoid this stack like the plague, but I write a lot of web backends in C#/ASP.NET (on Linux deploying to k8s) and it's great!
Do it. Build on the work of AwesomeWM probably, it's a Lua focused window manager that's quite nice. You can also build up less "minimalist" widgets and whatnot using Lua and claude code, which is very good at unconventional GUI work in Lua. I can attest to this specifically, I've had it build numerous GUIs with mpv Lua userscripts.
That is pretty much what we've done, but not in as "narrow" a scope as just Desktop but more as 'everything user facing in computing'. Full breakdown will be covered later this year as 'Arcan As OS Implementation' in a section on "Lua at every layer".
It’s truly fascinating that it was out of tune because of the similarities of the Mark II timing with sound itself .. but that also computing rapidly, rapidly started operating in a much higher frequency band and is capable these days of bending audio realities in other astonishing ways ..
Well, I have been a long user of Hammerspoon, and Lua, so thanks for the great app, it made a difference for me for a long time .. would be happy to hear why, but don’t feel obliged, the switch to JS over Lua, but anyway, thanks again!
The simple answer is not having to maintain a really complicated language bridge anymore.
The more complex answer is that Hammerspoon is currently about 100k lines of Objective C, and none of us really want to work on it anymore when Swift is the much nicer place to be doing macOS development.
Technically we could slowly convert in-place from ObjC to Swift, but there will always be a need for "LuaSkin", the bridging code we've accumulated over the last 13+ years, and rewriting that in Swift would be significantly complicated.
JavaScript, however, is already bridged for us because WebKit needs it.
.. but that’s mostly because LOAD81 is just fully great as well .. I’ll have to dig into kilo a bit and see how antirez’ two editors compare with each other ..
Done stupid stuff like this enough times that I just use tar, and also make a sandbox directory to receive it, to double-check whats going to happen, before un—tar’ing it again into the destination intended and/or do a manual move.
Too many burned fingers to not do this little dance almost every other time.
Actually, I lied, I just use rsync like an insane person.
It has to be said that one of the reasons a single header library is so useful in the C/C++ world, is because it makes interfacing to Lua so much sweeter.
I forked it and gave the robot work to do through my structured way of things. Seems to be working so far, with some added extensions to the original: https://github.com/Keyframe/canvas_ity_c89
As in, what if there was a Linux distro that focused, primarily, on building a Lua layer on top of everything, system-wise. Just replace all the standard stuff with one single, system-friendly language: Lua. C/C++ everything as it currently is: put Lua on top all the way to the Desktop.
It’s only a thought experiment, except there are cases where I can see a way to use it, and in fact have done it, only not to the desktop, such as of course embedded. Realtime data collection, processing and management. In this case, it is superlative to have a single system/app language on top of C/C++.
So I think there may be a point in the future where this ‘single language for everything’ becomes a mantra in distro land. I see the immense benefit.
Lua table state can be easily transferred, give or take a bit of resource management vis a vis sync’ing state and restoring it appropriately. Lua Bytecode, itself, in a properly defined manner can serve as a perfectly cromulant wire spec. Do it properly and nobody will ever know it isn’t just a plain ol’ C struct on an event handler, one of the fastest, except it’ll be very well abstracted to the application.
Oh, and if things are doing bytecode, may as well have playback and transactions intrinsically… it is all, after all, just a stream.
App state as gstreamer plugin? Within grasp, imho…
reply