ucode (ECMAScript like language) in Luanti?

[xshslgj]

Am I the only one who finds Lua a pain to work with when building larger mods and games? The way Lua works means it is complex to build anything that requires a lot of complex logic or data. The folks at OpenWRT felt the same way when they were using Lua in OpenWRT. The solution they came up with is called ucode and it seems to be a lot more powerful. It resembles Javascript like any other ECMAScript language but it isn't quite feature complete. the biggest difference is that ucode is designed to be small and embeddable with a focus on templating.

https://ucode.mein.io/

[v-rob]

No, I don't have that experience at all. JavaScript and Lua have quite a few similarities, but I find Lua to be by far the simpler and better designed of the two. However, making something in either language is of comparable complexity as long as you understand how to utilize the features of each language properly. I'm curious as to what you find causes programming in Lua to be so complex as compared to other dynamically typed languages.

Moreover, I don't see any advantages of ucode. Templating is quite unnecessary for modding in Luanti. I don't see a particular need for most of the other design criteria they list on that page either (such as distinct array and object types--ever tried storing non-string keys in a JavaScript object? Now try with a Lua table). We already have a lot of the other features listed implemented in Luanti, and Lua is widely known for its small and embeddable nature. Even if we were considering adding support for other programming languages, I can't see a reason to use ucode or other JavaScript variants.

[Blockhead]

Personally I'm much more familiar with Lua than JavaScript. It's a simpler language in fact. For those who really don't like it, there is a TypeScript transpiler, which has been used before for projects like mineos. And that is where I think other languages for Luanti will stay: transpilation and not first-class support. Because there is little benefit to be derived from the engine developers' perspective to providing another language to compete for support time.

Templating sounds maybe useful when you need to spit out firewall rules or interface configurations or other router things. In Luanti, you can put node, entity etc. registrations in loops if you really want, but often there are enough differences between things that you don't actually end up preferring it unless you're dealing with multi-state nodes like Advtrains signals or a furnace that's on/off, that sort of thing.

We have the bitop library, and Lua tables are already divided into array and hashmap parts. There are more API functions than standard Lua, such as table and JSON serializers, string.split, string:trim() and others.

Some of the features of ucode are undesirable (at least by default) in the sandboxed Luanti environment, such as sockets. Any mod that needs external network connections like HTTP needs to request that. Some people do install LuaSocket for their mods.

P.S. Your linked website commits one of my favourite pet peeves, northern hemisphere bias. "Spring 2021" for me was September, October and November.

[LMD]

Am I the only one who finds Lua a pain to work with when building larger mods and games?

It depends. Lua suffers from being a scripting language; it doesn't offer you the amenities of a more static language, e.g. static typing.

You need to make up for this with discipline; the language doesn't force you to be very disciplined.

But if you (and your collaborators) know how to structure your Lua code, it is possible to work with it at scale.

You can also consider preprocessors to get static typing.

But, let me reiterate: The main problems are pretty much shared among scripting languages.

The way Lua works means it is complex to build anything that requires a lot of complex logic or data.

That is complex per definition. This sentence makes no sense. Lua doesn't make things needlessly complicated.

the biggest difference is that ucode is designed to be small and embeddable with a focus on templating.

Lua is small and embeddable. This is not a difference. And the templating doesn't matter much to me (and I don't consider the way ucode does it particularly pretty).

---

To be blunt, this is an absolutely terrible suggestion.

First of all, ucode is incredibly niche. Look at any language popularity index and it won't even show up. This means you get a terrible ecosystem (and no, their JS-likeness doesn't save you, because it only goes about as far as syntax highlighting). No luarocks, no luacheck, no community, no learning resources, just someone's "invented here" language.

And that's not all: Performance matters a lot. Lua has LuaJIT. Where is ucodejit?

In contrast, choosing an established (especially in gamedev) language like Lua is a much better idea.

Okay, but that's a cheap (but nevertheless extremely important!) ad populum; maybe this is the hundred year language after all and everything would be great if we used it.

If we did decide to support another programming language, we'd have a mess where we need to support both Lua and this other language (and interactions between them); so it should really bring substantial improvements and not just unnecessary fragmentation and diversion of maintenance effort. Does this language? The answer is a definitive no.

Ucode utilizes reference counting

What about the significant cost of reference counting? Also: The mark-and-sweep GC to handle cycles needs to be called manually?

Data types: [Boolean, Integer, Double, String, Array, Object, Null]

Where is userdata? Where are threads? Where are maps with non-string keys?

The looping constructs seem to be lacking repeat-until, tail recursion, and custom iterators (which Lua's generic for supports).

The switch statement is inherited from C, with ugly fallthroughs, and is basically just a bad way of writing an if-elseif-else chain. Very bad design.

[relational operators:] if both are objects or arrays, their underlying memory addresses are compared.

What a footgun to put in a language. {} < {} should be an error.

In all other cases, both operands are coerced into numeric values and the resulting values are compared with each other.

Oh yeah, I can see how that's inspired by JS. Maintainability go brrr! Obviously true > -0.34. But not true > NaN!

Also, where is this "coercion" even defined properly?

Where is the error handling? The "syntax" documentation leaves a lot to be desired.

If the input is not an array, string, or object, length() returns null.

Right at it again. This should throw an error, not silently return null.

The stdlib straight up pollutes the global namespaces with names like "index", "rindex", "push", "pop", "unshift", "shift", "map", "filter", "sort", "reverse", "uniq". And of course, all of them have no proper errors, but just return null if you pass a non-array.

Objects have the same thing where all functions operating on them are just shoveled into the global namespace.

This is bad design. But hey, at least it's not OOP!

I don't even see a proper way to do OOP. No metatables, no prototypes, no classes. Am I missing something?

Now we can answer

The solution they came up with is called ucode and it seems to be a lot more powerful

It is not. It is in fact a lot less powerful.

There are arguably some stdlib features, but many of them would need to be sandboxed properly (or already exist) in Luanti, and essentially all of them have established Lua libraries that would get the job done just as well.

And the core language is just much worse.

For adding support for another language to make sense, it must offer significant benefits that make the massive effort worthwhile.

And these just aren't there. Quite the opposite: This language is far worse than Lua. It's a crippled JavaScript at home.

Also: It's just not a general purpose language. A general purpose language doesn't have "arrtoip" in its global namespace.

---

Pet peeves:

• IEEE 756 (it's 754)
• Attempt to modify a const value is called a "syntax error"
• They straight up forgot to mention functions when listing types?
• "Divisions by zero result in the special double value Infinity" - that's not how IEEE 754 works. -1/0 is -Inf, 1/0 is Inf, 0/0 is NaN.
• I see no proper documentation of closures whatsoever? But reading the source it does seem to have some concept of upvalues.
• Weird quirks, like no null bytes allowed in object keys. I don't think this language is very mature yet.
• Might just be me, but many parts of the documentation give off AI vibes.

[Astrobe]

And these just aren't there. Quite the opposite: This language is far worse than Lua. It's a crippled JavaScript at home.

Both making games and languages can be easy with the right tools, but the hard part is designing them right. It generally takes ten years for them to stabilize and acquire a significant user base - when they actually are good enough to survive that long. It is a long process of trial and error, even if you did your homework. The second system effect takes various shapes.

[Wuzzy]

The ultimate killer argument against switching to any other scripting language, no matter how much "better", is always: We have tons of existing Lua mods and games, and we would lose them all.

If you plan to add *additional* language support instead, i.e. supporting it alongside Lua, I also have a killer argument against that: You're increasing the complexity of Luanti MASSIVELY, not just of the application itself, but also the development. Great, now for every feature in the Lua API, you have DOUBLE the maintenance cost, double the documentation, double the testing, double the learning requirements for modders, etc. etc. It would also massively increase the complexity of game code, there’s a risk of it become a weird mess of two languages. And all that just so your code is of a language you like more. A steep price for a very small reward.

I think adding a whole new scripting language to Luanti would go down in history as the most disastrous decision the core dev team has ever made. But I know this suggestion has no snowball’s chance in hell to be ever taken seriously anyway (CORRECTLY), so I’m not worried.

I won’t deny that Lua has flaws, but these flaws are managable and for the purposes of Luanti, it’s perfectly fine.

These “we need to switch to language X” discussion keep appearing in this community over and over again but sorry guys, at some point you just need to deal with the cards you have been given. Luanti’s scripting language is Lua, and it’s not gonna change. Especially not when the reasons for switching are so weak. We should instead talk about how to improve the Lua API instead (for example).

[Blockhead]

These “we need to switch to language X” discussion keep appearing in this community over and over again

I just see this as nothing more than that we keep seeing new members come in who have grand designs over something they're not familiar with, nor are they familiar with the rationales uses to keep the status quo in place. It's fine to question it, but yes, they never do manage to write anything convincing. The closest we might have gotten is proposals about adding some concepts from Luau (from Roblox Corp).

The whole "you can use LuaJIT OR our modified PUC Lua" is a bit of a mess to begin with, and I wouldn't mind the idea of moving to a 100% backwards-compatible new single interpreter (or even a 99% backwards-compatible one for 6.0). Although I guess being able to use PUC Lua means more operating systems can be supported - I think it's a pure C program rather than the assembly that LuaJIT uses.

[Linuxdirk]

“I don’t like it, we should switch to something else!”?

It resembles Javascript like any other ECMAScript language but it isn't quite feature complete.

So it is an incomplete downgrade from Lua to Javascript-like?

the biggest difference is that ucode is designed to be small and embeddable …

Like Lua.

[Astrobe]

Although I guess being able to use PUC Lua means more operating systems can be supported - I think it's a pure C program rather than the assembly that LuaJIT uses.

Yes, JIT generates machine code on the fly, at runtime. It's like compiling the script to a "binary" program, except that the JIT only compiles the parts that are very often executed. So it is a bit more complicated than just embedding a small native code compiler in Luanti and compiling all the scripts at once before startup (because it would slow down startup, and also JIT can use data only available at runtime to optimize the generated code - something that an "a head of time" compiler cannot do; it has been observed that in some specific cases JIT'ed Javascript was faster than C thanks to that).

PUC Lua is a standard "bytecode" interpreter. That is, it the source code is translated to something one can see as machine code for a virtual processor.
Then the core of the interpreter executes this bytecode. It works very much like an emulator/virtual machine, like QEMU or Virtualbox, except that the emulated processor doesn't exist in silicon.

Lua has an option to output the bytecode it generates in a file. This allows to skip the analysis of the source code (syntax etc.) and to start faster. The generated file is as portable as the source code: you can "compile" it on a PC (x86) and feed it to a Lua running on a Raspberry Pi (ARM).

For this reason, this core is sometimes called "virtual machine" too. That's really the same thing. The "virtual machines" everyone know (like Virtualbox, VMWare,...) are a specific yet common case, because they emulate a real processor on the same real processor (often x86 on x86), so there's almost no emulation and the machine code inside the virtual machine is just executed directly. Their actual job is mostly to emulate peripherals (e.g. disk drive as a file on the host, relay keyboard inputs from host to guest...) and sandboxing.

Amusingly, there are a few cases of languages being implemented like this, bytecode and virtual machines, that ended up becoming "real" machines.