Why Lua?
closed
Chaser Zaks
As a programmer, I've never been a fan of Lua. It's cumbersome, and tries to "do things differently" than every other scripting language.
Take for example array indexes. Everyone is familiar with index zero being the first entry of an array. Lua uses index one. Going back and forth between the two when trying to interface stuff with LSL is going to be a pain, because if I have a index that is entry 14 in LSL, it will be entry 15 in Lua.
Or how everything is separated, and there is no object model, except for when there is a object model, but the decision of a object model is completely random. If you want to insert into a table, you don't do
MyTable.append()
, or MyTable.push()
, you have to call the "table" object, which has a function "insert": table.insert(MyTable, MyValue)
.Another is Lua's bitwise. I forget what the functions are specifically, but I remember when I had to do stuff in Garry's Mod, if you wanted to do bitwise operators, it was stuff like
bit.xor(a, b)
instead of what everyone else does like a^b
.Don't get me wrong, I
really
appreciate that there is effort going to do client side scripting, and it would be hella useful, but I don't see Lua as the future. It's been dying out of favor from what I've seen, even Garry Newman (The creator of Garry's Mod) has fallen out with Lua. (https://garry.net/posts/i-fell-out-of-love-with-lua)It would make more sense to use a language that is more in-line with what people are familiar with, such as Python or JavaScript. If sandboxing is a issue(EG: Preventing file access), the V8 engine is what NodeJS uses. NodeJS just implements interfaces such as file access into V8. Otherwise, V8 is just a engine for JavaScript without any bells/whistles. (https://v8.dev) Javascript even comes with the benefit of being able to do WASM, which is almost on par with native machine code.
If Lua is ultimately the decided language, I really
really
do not see myself using it. I had to use it recently to implement interfaces for a DNS service(PowerDNS), and it was horribly painful to work with, because it felt like everything I knew about programming was thrown out the window.I highly ask that a second look be taken on which language to use for client side scripting, I really do not feel that Lua fits with Second Life, and that there are much better choices to choose from, especially ones that would better align with what people who do programming in Second Life are familiar with.
Log In
Signal Linden
closed
This is a good question and it deserved a longer form response: https://wiki.secondlife.com/wiki/Lua_FAQ
If there's more questions Server team engineers would be happy to chat during the Server User Group.
NaomiLocket Resident
Considering that LUA is the configuration language of Neovim, and plenty of career programmers opt to use Neovim and by extension LUA - you can consider LUA to be backed by professional programmers.
Even ones that on occasion make a joke about the index actually being the subscript in other languages.
All the other C-like languages might have been stuck with the convention simply for C being a protocol and interop instead of the language it used to be by opinion of some that work or observe that space. Or so I have heard at least.
nya Resident
Well after hearing the news of server side Lua scripting, it's fairly clear why they're choosing this path.
Some speculation...
- Great language for beginners to pick up
- Plenty of resources to learn from
- Already has a wide adoption, and large active communities
- Ticks the standardization box
- Quick and easy for small teams to implement properly, and safely
Gwyneth Llewelyn
Just a comment here... it's not really relevant how much programmers "like" Lua or not. I would also guess that programmers hate LSL as well — but it has been used for twenty years by tens of thousands of programmers. I tend to agree that
some
constructs in Lua are weird, but, then again, I'm a Go fangirl myself, and I'm always amused how the Go developers have implemented so many things that Lua already had (hint: the core Go developer team is behind the very first C compiler, so they have had 55+ years of experience in writing compilers and developing programming languages...).That said, it seems reasonably obvious to me that what matters here is the level of "containership" (does that word even exist?) that you can demand from an embedded engine for client-side scripting. JavaScript started as a small thingy and evolved in the massive mega-engine that V8 is today — but over the past two or even three decades, the JavaScript developers have dealt with
billions
of users running it on their pocket computers (a.k.a. smartphones) and have consistently cleaned all possible bugs and security holes as fast as they were discovered. One reason for using JavaScript is not because the language is any good, or because people "love" it: it's because there is a very long development process behind it, which is quite mature, very well documented, robust, and secure. So, even if I personally also
dislike JavaScript, I cannot bring any serious argument against
using it.Lua is different, as explained elsewhere: it's been around since the dawn of the web (1993) but it was not designed explicitly for the web (as JavaScript originally was). Instead, it was designed from the very first day to be an embedded language, with all that entails. It's very different when you start with a programming language and pull and stretch it to do whatever you need it to do (e.g., JavaScript, PHP, Perl...), or when you design it from scratch to do something specific, and do it extremely well (e.g., C :) — for systems development — but also things such as PostScript).
Lua is rock-solid, and has been so for eons — even though it never became as popular as JavaScript, of course — but that solidness comes from many, many design features from the very start. Even in it's purely interpreted form, running on a virtual machine, Lua continues to be one of the very few (and certainly, among these, the most popular) which uses a register-based bytecode engine. All others — and that includes JavaScript, Java, PHP, Python, and whatever else you care to name — use a stack-based virtual machine, mostly because, well, that's how interpreted languages are supposed to work. It's also the best-known method of developing a virtual machine, and the one that allows the widest possible portability (
any
CPU can run a stack-based machine!).But it doesn't mean that it's the
best
or the fastest
way of running bytecode.That's just one of many examples why Lua is so interesting. If LL had decided to use Lua instead of LSL, they would have been astonished at how quickly they had implemented everything, and at the performance they could have squeezed out of a Lua VM. And, today, instead of having a mega-library of hundreds of functions, which only gets more and more complex, we'd have a simple library-based model, loaded on demand, like on any other modern language. And this was certainly available back in 2003, when SL launched. It was even fully available in 1999, when LL was founded. There were already several games using Lua internally by that time. JavaScript obviously was also around, but it was still too bound to a browser, and not really a good choice as an embedded general-purpose language, so to speak, because that's not what it was supposed to be!
And, of course, you could have any variant of LISP, the oldest of all embedded programming languages in the world (est. ±1959). At some point in the 1990s,
everything
that had a built-in embedded language simply used a dialect of LISP. That was true, say, for AutoCAD. Not to mention Richard Stallman's Emacs. LISP is certainly one of the best choices out there, and will continue to be, if LISP is all you need :)It's
not
a coincidence that many applications which required a built-in, embedded language, and which opted for LISP at the turn of the century (just because it was the easiest and most well-known choice), are now slowly moving to Lua. The main reason is that LISP requires a different mindset altogether, since it has little to do with how a majority of programmers think of a "programme flow". Most
contemporary young programmers leave their universities learning just Java, C# and JavaScript, possibly with a bit of C and C++ just to have a taste of different flavours of C-like languages. All these languages have a common root (C!) and are therefore learned pretty much in the same way; variants of C are simpler to learn than radically new languages.LISP is too alien. Lua, by contrast, is clearly inspired in the Algol/Pascal/C family, while having its own quirks. It's probably the most typed of all untyped languages I've worked with :) But it still follows a common thread that started with Algol in 1960.
Interestingly, LSL is an example of something that
looks
like TypeScript (more than JavaScript — LSL is strongly typed, after all), but conceptually built around an event machine — which makes a lot
of sense, really. One might argue that the same can be accomplished with Promises under JavaScript (and any other programming languages that have a similar concept). But Promises are a recent thingy in the long JavaScript history.Anyway... to summarise... because I could discuss programming languages all day (and never come to any conclusion that everybody could agree with)... my point is that today, in 2024, you have
realistically
four options for implementing user-scripted, client-side plugins:- LISP
- Lua
- JavaScript
- Python, if you're insane
To be 100% honest, there is no real alternative. There
are
, for sure, tons of "experimental" and conceptual embedded languages out there, but none have been as thoroughly tested and documented as these.However, I'd be curious to see more WASM being deployed — basically because you can use whatever programming language you prefer (assuming t it includes a compiler to WASM, that is) and just compile to WASM bytecode (insane people like your truly loves to deploy fully-fledged GUI applications written in Go, of all languages, and just compile to WASM to embed them on a browser — like React in Reverse, so to speak!). However, I agree with all other commenters who pointed out the potential security pitfalls of running a WASM machine on top of the SL client — WASM
can
be dangerous to be deployed outside of a browser's sandboxed environment: one mistake in the implementation of the VM, and you're doomed. The other embedded languages already have their VMs fine-tuned and thoroughly debugged in order to be safely used inside another application. So, stick to what works and what is safe to use :)Send Starlight
I agree with you that JavaScript would have been the perfect fit. I don't mind Lua, though, and I'm in the anything but LSL camp. Though, unfortunately, if they're deadset on Lua they're locking themselves into a language that is contrary in design to literally every other language out there so I definitely see your point of view. They're not preparing developers for the real world, almost no one uses Lua anymore and not really for anything serious when they do. This is going to be a language we're stuck with for a very long time on the platform sadly. If they had picked something like JS literally everyone in the world knows it. Though, honestly even Lua is a relief, they've saddled us with LSL far too long. I'd take Pascal at this point.
WolfGang Senizen
I know that lua is pretty much locked in afaik.
But I'd like to throw wasm into the "ring" as a direct target not via v8, just a straight wasm runtime.
With GC now in the formal spec there is very little preventing any language from compiling to / running on wasm directly.
For instance https://github.com/web-devkits/Wasmnizer-ts allows you to compile typescript directly to wasm.
There are aslo several projects that allow lua to run through wasm.
It may however unfortunately be a little too soon to integrate easily, as the C and C++ api is still a phase 1 proposal. (https://github.com/WebAssembly/wasm-c-api) but is implemented in wasmer-sdk for instance (https://github.com/wasmerio/wasmer/tree/master#wasmer-sdk)
It would however be harder for a new user to pickup without a premade workflow, or some sort compiler for say lua bundled with the viewer somehow.
Send Starlight
WolfGang Senizen LL probably has to consider heavily the security issues presented by swapping a new scripting system in and Wasm would probably have made them nervous. They do unfortunately have to deal with a pretty critical rogue faction on their platform that tests the boundaries of what is possible on a regular basis. If I had to guess that might be why they leaned towards Lua.
WolfGang Senizen
Client side that should be less of an issue, people are already using TPV's, for which they just download arbritary binaries for, as long as there is no way to load unsigned/unverified (see my suggestion) remotely then that security aspect is pretty much mitigated.
And wasm is designed to allow remote loading of arbritary code, so its view of security will likely be above and beyond most lua implementations, which are generally designed not to load arbritary remote code (roblox being probably one of the few examples of where it does i can think of)
Bleuhazenfurfle Resident
Lua's ugly, true, and I don't much like it myself, either. But it's not much worse than JavaScript, which also suffers from those same criticisms; Map vs. Array, as the simplest example. (Mainly as stress relief, many of my JS/TS projects contain an ever-growing file with a list of all the annoying horrible things JS does badly, which have caused me bugs in the project.)
I do also think Lua is probably a little more "beginner friendly" than JavaScript — though it is also a very distinct language, so coming from LSL, JS might be less of a shock. On the other hand, that may be a disadvantage — looking too similar, might well also be it's own source of confusion (especially being one is typed, and the other is not, some operators will have different precedence, etc.). Also, Lua isn't the first language to use 1-based indexing, I grew up on Pascal which lets you choose your own start index (and I distinctly remember starting with 1-based, and slowly gravitating on my own, towards the 0-based indexing we all know and love).
And Python, unfortunately, is really hard to sandbox — the curse of a language being "too powerful"…
Lastly, the Lua and JavaScript interpreters are at least specifically designed to be running potentially unsafe foreign code. (Seriously, JavaScript should never have been let anywhere near the internet — but, it's what we have, and a LOT of effort has been put into making it both performant, and safe.)
Personally, I'm ambivalent on the Lua vs JavaScript debate, and totally think C# on both sides would just be better all round, but either is a far sight better than some obscure scripting language almost no one knows (I don't recall hearing of the two previously mentioned here, and I've got a square dozen distinct real languages under my belt — over two dozen if you count esoterics and variants as well). A language that people actually use (unlike those other two, or LSL for that matter) also means there's plenty of resources to learn from (and ChatGPT might actually produce working code — maybe that's a bad thing).
Send Starlight
Bleuhazenfurfle Resident I love C# but it probably would have made a terrible scripting language, unless they integrated blazor or something. C# is just a bit too wordy otherwise. JS, Python and Lua make better options but each have their own caveats. I think a well tightened JS would have been the best bet. But, I'll take Lua over LSL tbh. Heck, let's stick Perl in there. xD
Bleuhazenfurfle Resident
Send Starlight: I'm repeating myself a bit here, but I think it's critically important for this application, not just looking at the languages on the surface. They have to fit the task, too:
I completely agree C# is too wordy, and I use it about as little as I can get away with – it was, after all, specifically Microsoft's answer to Java. The key as far as LSL is concerned, though, is that it compiles to the same bytecode engine they're already using (Mono), and it has "compiler as a library" facilities already in place that have been used for exactly this purpose, with hooks and all the lovely things to let it be sandboxed and twisted as necessary — and like Lua(u), it's already proven to the task. The biggest downside I think C# has, is it doesn't really have a simple mode — you've pretty much got to jump right into the fire (at least, that was the case when I was first learning it, that might have improved since).
In Lua's defence, it's a pretty complete language, though some things in it are rather painful. Most importantly though, it was intended for just this purpose, and Luau apparently doubles-down on that — they not only get a language both intended and proven to the task, but in a practically ready-made package, complete with a bow on top. As much as I'm not fond of it personally, I'm not in the least bit surprised they went with Luau for this.
As for JS… JS isn't fit for anything. It's a wonderful academic language — for the same reason Klingon gets taught in universities; it's a master-class in how
not
to design a language (though Klingon was designed that way intentionally). JS is also woefully incomplete, inconsistent, and has the feel of two different languages glued together in many places, and I'm sure is popular only
because it was shoved into an existing empty space, and by pure fluke, nothing decent has been able to dislodge it. That said, like Luau, the JS engines are designed to run untrusted code from the get-go, there's a raft of limitations in the language specifically to support that environment (because it wasn't designed to support it initially — it was barely designed at all), and a lot
of time and money has been spent making it performant, despite itself (not to mention shoring up the remaining holes).Python (my personal favourite out of this group) is a proper consistent and comprehensive language, everything you'd want, but it wasn't designed to run untrusted code and coercing it to do so is a major challenge (I've seen a couple efforts, but nothing concrete that could be applied here). Unfortunately, that power, expressiveness, and flat out capability that makes it so popular, also makes it seriously hard to optimise, although JS has shown the way (hard-core JIT'ing) and they seem to be finally starting to tackle that issue proper (Python has JS's difficulties with optimisation, but squared). As much as I love Python, I can't see it being a serious contender here, especially where untrusted code is a concern.
So all up, I see C# and Lua being the only viable options so far, out of everything that's been suggested to date. (And I'm not even going to grace Perl with a response — it gets a dishonourable mention.)
Send Starlight
Bleuhazenfurfle Resident Oh, I was joking about Perl. But, it's not such a bad language pretty performant and fairly easy to code in tbh. It gets a bad rap for being difficult because regular expressions, which is its strong suit, are hard in general to understand. But, I'd never use it for embedding into a game. They could use Visual Basic .NET... ;D
Imaze Rhiano
LUA is good enough for very simple user interface scripting - but it is not good enough for larger viewer side projects - like games. Choosing LUA as your scripting language is going to limit SL viewer to simple user interface mods.
I don't understand why to go this way. Yes - integrating heavy duty languages like C# would have needed more work - but would have given much bigger platform to build applications for SL. This is going to hurt you in future, when you want to expand SL viewer out from its box.
Gwyneth Llewelyn
Imaze Rhiano not necessarily true. See how Adobe Photoshop, Autodesk (AutoCAD, Maya, and their ilk), or even Blender — and Emacs! — deal with expansions to their core applications. The application itself is written in one programming language; the extensions/plugins/expansions/external modules are written in something completely different, and even that doesn't remain static forever (except, well, for Emacs, which is — and always will be! — written and expanded in its own dialect of LISP). E.g. Photoshop used to require compiled-in plugins — a problem when porting from the Mac to Windows or vice-versa — and slowly moved to allow Python and now even Lua. AutoCAD used Autodesk's dialect of LISP, but over the years it started accepting others, too. Blender is also mostly Python and Lua, if my memory doesn't fail me. Lots of others (VLC comes to mind) have started by allowing a
lot
of different programming languages, but, over the years, converged towards Lua (not because it's the "best" choice, but it's likely the fastest to integrate).Also, you
can
extend the SL Viewer today
via LEAF — which is language-agnostic, since extensions/plugins are supposed to run on their own processes anyway. Internally, LL seems to be exploring LEAF plugins written in Python, but that's _their_ choice; you can use C# for that if you wish.No, the question here is to give end-users a
simple
way to be able to script changes to how the viewer
presents information — beyond simple XML-based styling, that is. We're not really talking about major changes, such as using the viewer as a component of a much larger system. Instead, I believe that what LL is aiming at is to have a reasonably standard (and secure!) way to do communications between the user, the viewer, and in-world scripts — such as it is possible to do with the Firestorm LSL Bridge, or the RLV protocol, used by every TPV, and notoriously absent from SL.It would also mean that things like HUDs would not require any in-world scripting, but would rather be elements integrated into the viewer, which just happen to communicate with in-world objects (and avatars). Similarly, parts of the whole system could (finally!) be removed from the "core" and pushed to the Lua VM — a good example being text chat, for example, or even inventory. After all, we do have
voice
chat running on an external process (via LEAF!), and have that for years and years, thus proving that there are many things that do not strictly require being a part of the SL environment as rendered by the viewer
) already — why not text chat?Crush Cutie
Ideally it should be the same language as used to script in world objects. It also needs to function the same. I would vote C# for both.
A language that is superficially like LSL yet inherently different isn't doing any of our skilled content & in-platform creators any favors, plenty of whom learnt programming with LSL.
Client side scripting lives and dies by the depth of it's hooks, it would be helpful if these were consistent between client and server side. Practical use cases require that they go extremely deep into the viewer code. Deep hooks raise all manner of concerns, not least of all security.
I find it notable that SL viewers have had LUA on and off before with minimal traction. The active implementation in CoolVL appears to serve limited use cases - Keeping Henri busy updating it, minor (extremely limited) viewer UI additions, edge case personal use automation.
There is no possibility client side scripting could even come close to the functionality built into TPVs with C++. TPVs are not "skins".
Kristy Aurelia
Crush Cutie C# is definitely a good fit. LSL states would pretty much map to a C# class 1 to 1, where each event handler is just an overrideable method.
Henri Beauchamp
Crush Cutie
C# is not cross-platform... and it is relying on an enormous runtime.
Lua got the immense advantages that it is small , its library can be statically linked to the viewer (no need for a runtime), it is designed with a C API making it easy to integrate in the viewer code, it is fast and easy to learn, it is dead easy to expand with custom functions.
As for my implementation, it is extremely powerful (you can design your own floaters, with your own functionalities, if you want, you can also run up to 8 Lua threads in the background and have them interacting with the viewer). You should read the manual more carefully before drawing conclusions. :-P
Kristy Aurelia
Henri Beauchamp Unity runs C# cross platform just fine.
Henri Beauchamp
Kristy Aurelia
The viewer does not use Unity !
Under Linux, to use C#, you need Mono or Wine-Mono, and either of them is not guaranteed to be available/working properly in all distros (some distros don't even compile Mono any more, others got totally outdated versions, and Wine-Mono means you need to install and run Wine too just to use a Mono application, meaning it won't even work within the viewer but would need a plugin system)...
It is also an enormous, fat dependency (including under Windows , with .NET) which is best not turned into a requirement to run the viewer !
Crush Cutie
Henri Beauchamp If a distro can't run mono off the shelf, it's not much of a distro.
Henri Beauchamp
Crush Cutie
Some have "switched" to Wine-Mono, with the rationale that Mono stuff is mostly Windows stuff... Yes, it is stupid, but that's how it is.
This is also the result of Mono not being properly developed any more for native Linux.
Jeremy Duport
Henri Beauchamp FWIW arch, redhat, and ubuntu are examples of linuxes shipping native dotnet packages. https://packages.ubuntu.com/jammy/dotnet-apphost-pack-8.0
Diamond Caudron
Henri Beauchamp Is Mono even needed for C# in Linux with Microsoft now providing open source .NET Framework for Linux, macOS and Windows? https://dotnet.microsoft.com/en-us/download/dotnet
Gwyneth Llewelyn
Henri Beauchamp just a small correction: for well over a year or so, Microsoft now ships the Roslyn compiler for Linux which does
not
require Mono, Wine-Mono, or anything else; essentially, the runtime is embedded in the binary, just like it happens for Windows.I'm not a C# fan (never was, never will be), but kudos to Microsoft, which have
really
turned their .NET environment to be fully cross-compatible (aye, it includes macOS and ARM64 variants).Then again, no, under Linux/macOS, you won't get a fully-fledged
GUI
— just command-line tools. But that might
suffice for client-side plugins.In any case, as said, I'm not a fan of C# and hardly believe it's a good choice for anything — much less client-side plugins for SL :) The argument "but Unity does it!" doesn't count. Unity
could
run on a LISP interpreter if they wanted — they compete in a niche where there are just two serious players (the other is Unreal) and a rising upstart (Godot). When you "own" the niche, you can decide everything you want, and the market will obey — there is no choice there, really.Kadah Coba
Kristy Aurelia Unity's C# needs to be compiled for each platform separately, which requires having installed the compilers for each platform. Even with the high level of support Unity has for this, it still has issues that require games to make platform specific fixes. Bugs in C# cause application crashes that are often near impossible to debug.
Jeremy Duport
Being the lowest common denominator of 2000s UI scripting does not equate to being the only option - or even a pleasant option. Lua is a major turnoff to be honest, especially with many equally embeddable and better-GCing options like (https://dascript.org) and (http://squirrel-lang.org/) floating around, many of which exist for the express purpose of addressing its significant shortcomings as a language.
Kathrine Jansma
Market share and knowledge is a significant quality of its own. While JavaScript probably dwarfs anything else in this domain, i would assume Lua is still at least a magnitude more know than both dascript or squirrel.
Load More
→