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.