Hacker News new | ask | show | jobs
by zackbrown 701 days ago
This is really cool. I've been building a GUI system in Rust that features an expression language[0] — and we ruled out using CEL a while ago because the canonical Go CEL interpreter would cost several megabytes of runtime footprint (e.g. in a WASM bundle.)

Haven't measured the footprint of cel-rust yet, but I expect it's orders of magnitude smaller than cel-go. The Go runtime itself is the culprit with cel-go.

This Rust implementation may let us port to CEL after all, while maintaining Pax's <100KB wasm footprint. Nice work!

---

[0] https://www.pax.dev

2 comments

> canonical Go CEL interpreter would cost several megabytes of runtime footprint (e.g. in a WASM bundle.)

At first blush Go seems incompatible with WASM in terms of maintaining Go's strengths—the two runtimes have different memory models and stack representations. I'm curious why one would choose Go if WASM were a target to begin with.

because very few people porting things to wasm understand the model more than they understand the abi they are compiling code to.

asm is a dead art.

I don't know why people don't just use Lua. It's extremely small, can be embedded only with the Lua modules you want it to include (e.g. you do not need to provide file system access, networking etc. making it similar to CEL, just better), can be compiled to every possible target being written in standard C, is very mature and is completely open source.
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.)
Lua is a VM and instruction limits can easily be imposed to kill programs like this. (This does not apply to LuaJIT)
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.
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.
One of the selling points of this language is claimed to be that it executes in constant time.
Honestly, I've ruled it out for 1-based indexing. Why deal with that mistake when you don't have to?
It's not popular enough. I love Lua (except for 1-indexing) but I can't use a language if nobody else uses it
The games industry isn't nobody, that is how Lua got its fame, being a common scripting language, before Unreal and Unity became the only two engines most people know about.
Lua has been around for ages. I've never heard of CEL before today.
Lua is in the running for most-used language, second only to, possibly, JavaScript.

Few people write just Lua (although professionally speaking, that was me for several years) but many people write some Lua. It adds up.