[jey]

The problem is that Lua is Turing complete, so you can write programs that don't halt or which take an input-dependent duration to halt. Example:

    while true do
      print("meow?")
    end

In contrast, each CEL expression has a maximum depth which directly determines how long it takes to execute. (More precisely: by calculating the maximum costs up the expression tree from leaves to root.)

[summarity]

Lua is a VM and instruction limits can easily be imposed to kill programs like this. (This does not apply to LuaJIT)

[kbolino]

The point here is that you know (at maximum) how many instructions will be executed before running it, and so if it exceeds the limit, you can avoid running it altogether, instead of killing it midway through its execution, leaving things in an indeterminate/corrupt state.

[IshKebab]

You don't. Even non-Turing complete languages can run for an arbitrary length of time. In general Turing completeness is never a relevant property in the real world.

[tines]

One of the selling points of this language is claimed to be that it executes in constant time.

[IshKebab]

Well, they claim "linear time". Constant time would be impossible.

But anyway they achieve that by being much more restrictive than just "not Turing complete", e.g. you can't define functions.

It certainly sounds like an attractive feature, but how much benefit is it really to restrict a language so much that it will probably run quickly enough compared to just setting a timeout or computation limit? The only advantage I can think of is that you get some kind of computation constraints that don't depend on the data... But this is a pretty niche requirement.

[kbolino]

It is a niche, yes. However, that niche is about adding some customizability to certain parts of a program, where Lua would be overkill. Moreover, hardening Lua, which is doable but not trivial, may be beyond the ability, interest, or simply time available to the developer. If you don't need the extra features Lua provides, why include them?