Lua as a practical "soft-bedrock" language
7 points by dzwdz
7 points by dzwdz
The popular "Penlight" library, which adds a lot of Python-inspired utility functions for string manipulation and similar generic programming tasks, made a new release in January of this year, mostly just to add support for Lua 5.5.
Ironic choice of example because if Lua really never broke anything then Penlight wouldn't need to release a new version for compatibility.
The main thing that this article overlooks is the fact that unlike practically every other programming language in existence, it's perfectly viable to just continue to use Lua 5.1, which was released in 2006. I don't think there is an official policy around which versions are EOL, (edit: was wrong about this; there is a policy but distro people keep it going) but Debian (and hence everyone downstream of Debian) still commits to supporting 5.1 and are not likely to stop any time soon.
Even if your distro didn't ship it, the fact that the whole VM is like ... 15kloc means you can embed it in your own repository and ignore whatever the OS ships, which neatly bypasses the tremendous headaches languages like python have had with OS-provided packages.
unlike practically every other programming language in existence
Has that really become a big issue? I mean, sure, there was the Python 3 brouhaha, but I probably can still write Perl like in the olden days, despite the language now features such modern features like formal function parameters.
And I would assume gcc and clang still accept K&R C, maybe gated behind a few switches.
Is Python more the rule than the exception?
I meant literally running the old version. In 2006 the current version of Java was 6. Try running Java 6 on anything nowadays. There's absolutely no way you could get running a 2006 version of Javascript. Ruby was at version 1.8.5 in 2006, which you definitely can't still run. I don't know much about .NET but I'd be pretty surprised if the version of C# from 2006 could still be run today. Today's gcc has compatibility with C code from 2006, but you can't actually run gcc from 2006.
Today's gcc has compatibility with C code from 2006, but you can't actually run gcc from 2006.
Isn't this reasoning going to rule out almost all compiled languages (including JIT)?
The first amd64 CPU came out in 2003. Intel released its first server-oriented amd64 CPU in 2004, started selling consumer amd64 CPUs around 2004-2005 (but the details seem very messy). AArch64 came out in 2011.
Are there any compilers that fit your criteria? TCC, maybe? Plan 9's toolchain?
Also, while I agree that Lua has excellent longevity, I don't think I'd really want to run a 2006 version of Lua. Looking through the Debian changelog for lua5.1, the last meaningul update was fixing CVE-2014-5461 in 2014, and there have been a bunch of fixes before that.
The first amd64 CPU came out in 2003. Intel released its first server-oriented amd64 CPU in 2004, started selling consumer amd64 CPUs around 2004-2005 (but the details seem very messy). AArch64 came out in 2011.
The original post is evaluating languages for use in permacomputing, so in that context I don't think it's unreasonable to discuss things that run on older architectures. But yes, architecture changes are part of why you can't do this with many languages. I don't think that weakens the argument; rather I'd see it as an additional reason bytecode engines are particularly enduring.
There were major changes in how Lua 5.2 handled modules that required modifications, which Mike Pall, author of LuaJIT, did not agree with. So that's probably the major reason why people still use Lua 5.1. Lua 5.3 made changes to the language itself (direct support for integers and integer operations like AND and OR) that may mean you 5.3 code can't run unmodified with previous versions. Lua 5.4 and 5.5 have added new language features as well.
You can still write code that works under 5.1 or higher, but it takes some work.
After completing the "smolnet captcha" I just seem to be getting gateway errors attempting to read this article. Is the capsule itself down, or just the proxy?
I'm getting the same thing, but I can load the capsule just fine in Lagrange, so there's something going wrong between the capsule and the proxy.
...I think the capsule has blocked the portal.mozz.us proxy. That's unfortunate. If I had to guess, the proxy doesn't do much caching (not that I think it necessarily should), and the capsule has blocked it as some sort of DoS mitigation.
Good find. I thought one of the advantages of Gemini was that it's much more cacheable being just static files, and so this sort of thing wouldn't happen as often—or am I thinking of another alt-web project?
(BTW it's been an hour since I last checked, and it looks like they unblocked it now.)
There are Gemini sites that are run on small computers like the Pi, and usually at home. Sometimes they get swamped. I know Solderpunk is into minimal computing so that may be what is happening. Also, there are Gemini sites that do block web proxies, since one point of going Gemini is to get away from the web.
The Mare Tranquillitatis People's Circumlunar Zaibatsu (zaibatsu.circumlunar.space) is a small (512 MB RAM, 12 GB disk) Debian GNU/Linux server [...]
It looks like the capsule, if I have the terminology correct? When I go to the main page on that same proxy, other sites load for me.
And not mentioned in the article is that the first Gemini server was, and still is, written in Lua. And as far as I can tell, it still is the only server written in Lua.
Disclaimer: I wrote this, and it's still running to this day.
See also the follow-up on Kelvin versioning:
This will be a relatively short post which nearly got included as part of last weekend's "Lua as a practical "soft-bedrock" language", but at the last minute I felt like I was cramming too much in.
I'm increasingly convinced that programming languages should be developed with the intent of freezing development at some point, instead of piling on more and more features. If you want something very different, make a new language, possibly with some kind of library- or bytecode-level compatibility to reuse existing code.
I don't think I agree, but I do think that languages should evolve a bit slower than they do today. I quite like C's slow progression, as it gives programmers time to acclimate to newer versions, find the pain points and suggest improvements.