You can't run untrusted code because by default code can open and write to the filesystem. Sandboxing is up to the application. For sandboxing wasm is a good alternative.

Removing the API for file access would be easy. Limiting compute time is the harder thing.

Yes, it is very easy to remove the entire standard library from lua. Could compute time be handled with signal handlers in at least some cases? If not, one (admittedly somewhat hard) option is to write a small lua to lua compiler that injects yields into loops and recursive function calls.

Limiting compute is trivial on any modern operating system. On Linux you can create a second supervisor thread, block on a mutex with a timeout, and then if you timed out before acquiring the mutex you can just tgkill the runner thread. On BSDs it's even easier since you can just hand the runner thread port to your supervisor thread and, after you timeout, you can just set RIP/PC to whatever location you want without having to screw around with signals.

I'd love to better understand what you're describing. Thread-level compute limits generally seem like they need to be managed in some sort of cooperative fashion, otherwise you end up with the possibility of dangling locks and other kinds of corruption on forcible termination.

What signal are you sending to the running thread? What's the handler look like? How does that translate to terminating the thread? How do you do this forcibly (without cooperation from user code)? Schemes that I have seen look more like generating/ instrumenting polling/checkpoints into user code.

You let it operate on a copy of the input data and check integrity afterwards. If it doesn't reach a valid state you discard it as failed/corrupted.

There are many pieces of process global runtime state that can get corrupted that are irrelevant to the input data.

You can get lucky and sometimes avoid corruption, but eventually you're going to hit something important like leaving a libc heap allocator mutex locked when you kill a thread in the middle of an allocation.

He's describing killing a thread using a watchdog.

This doesn't limit compute power of the thread.

It's an all or nothing approach; either the thread runs or is killed, which doesn't work (as you point out) for all circumstances where you want to limit the amount of compute pwr a thread can use.

They're describing sending a signal to a thread, not "killing" it. IIRC, the only thing tgkill is going to do for you is ensure which thread runs the signal handler. For example, if you send a SIGTERM, (IIRC), you will terminate your entire process.

The comparison with Lua is the most interesting to me. Most companies I worked for used Python as a shitty proxy or CLI tool, but I never could recommend Lua due to its confusing OO system (meta tables??)

If this language is a valid alternative with a simple struct and a basic constructor, I may recommend it to remove all the Python scripts and their dependencies.

Having a lot of experience wrangling prototypes in JS was a nice benefit to my first forays into lua, though I wrote more functional code than OO anyway.

Honestly, off by one errors due to indexing was a lot harder to shake than getting used to meta tables.

I’m assuming that the indexing off by one errors were due to Lua 1-based indexing? If so, was it due to you being used to 0-based indexing or something else?

Just curious. I’ve been kicking around some attempts to make programming simpler (though hopefully no less powerful) for casual programmers. Lua’s 1-based indexing gets a lot of critiques and, while I haven’t written a ton of Lua, can’t help but think that the critiques are due to us all being used to 0-based indexing. Which is a valid critique, especially for a scripting language, but one that applies less to novices.

This is somewhat inefficient but zero indexed strings can easily be simulated in lua:

  local array = function(backing)
    local res = { len = function() return #backing end }
    setmetatable(res, {
      __index = function(_, k) return backing[k + 1] end,
      __newindex = function(_, k, v) backing[k + 1] = v end
    })
    return res
  end
  local x = array { 1, 2, 3 }
  print(x[0]) -- 1
  x[1] = 5
  x[x.len()] = 6
  for i = 0, x.len() - 1 do print(x[i]) end -- 1\n5\n3\n6

Bingo. All of the languages I have used prior to (and since) use 0-indexed arrays.

There's times where doing math with array indexes is simpler with 0 and with 1-indexed arrays. I don't think I really found 0 to be difficult to learn; there are a great many more challenging things.

I wouldn't say "don't use a 1 indexed language" but I've also never found the arguments in favor of it to be compelling when using lua.

Metatable types are indeed kind of awkward, but it's pretty easy to build a type system on them in a library. Check out metaty where I built a type system, formatter and deep equality checking in like 700 LoC. I'm adding the ability to document types/functions as well, after which it will be "done"

Would you have a link? my googling skills have failed me

An native thread management with an `async` keyword would really make it stand out from Lua for game engine uses.

I wouldn’t call that “stand out” especially when it comes to game engines, game engines are very complex and they are all different from implementations to their algorithms having a native thread management keyword does more worries than stand out