As others have noted, this is not actually a Lua engine written in Rust. It is a wrapper over existing C/C++ implementations of Lua. There is, however, an actual Lua engine written in Rust. It is called piccolo.[0]
That's exactly how the term runtime is consistently used in the JS world... not sure it's misleading at all. Certainly less exciting/ambitious than if the interpreter was also rewritten, but its what it says on the tin as I understand the words.
Not sure what this is. The homepage shows making an API in Lua. So is a web framework?
In any case, a bad description term-wise. Being referred to as runtime made sense for Node & JS, since JS was until Node mostly confined to web browsers with Node setting it free giving native OS access, an event loop, and even a module system. Lua, Python, etc are already shipping as their own self-contained runtime. So calling a Lua, Python, etc wrapper in X as runtime written in X makes no sense.
The "runtime" word is very confusing in this case.
It's a web application server written in Rust (Axum/Tokio), that has hooks into Lua bindings (mlua) so that application behaviors can be implemented in Lua.
It seems to just be re-exposing existing lua runtimes, which makes the naming very unfortunate IMO. The underlying runtime Luau, for example, details its performance here https://luau.org/performance . Luajit is already popular and has plenty of benchmarks online.
Looks neat. I built a programmable server for Server-Sent Events using a similar stack (Rust/mlua/axum) [1]. I think the Rust/Lua interop story is pretty good.
Correct me if I'm wrong, but it looks like this is using the mlua Rust bindings (which are excellent). It's not a Lua runtime from-scratch in Rust. It's the regular C Lua/LuaJIT with a Rust interface.
You're thinking of the interpreter, not the runtime. The runtime is libraries, not the interpreter. The async-io frameworks and stuff like that. Just like how node.js is a javascript runtime, it uses the V8 engine, and bun is also a javascript runtime that uses javascriptcore instead. Neither one of them wrote their own javascript interpreter.
I think of the runtime as the whole execution stack. The interpreter, engine, JIT etc. is the back end. The interface to the world is a wrapper around that.
I would describe this as a Lua wrapper written in Rust. That carries the clear indication that you should not expect the interpreter to be written in Rust.
I would be (and indeed was) disappointed to see that this 'Lua runtime' did not have a Rust implementation of Lua. I would be much more interested in seeing that than a wrapper.
The first sentence in its readme is the following: "Astra is a web server runtime for Lua (5.1-5.4), Luau and LuaJIT written in Rust with native support for Teal."
The interpreter/jit has traditionally been considered part of a dynamic language runtime, arguably the major part, before JS-brained companies started to call their every repackaging of V8/JSC a runtime (which is technically correct but only considering part of them is off-the-shelf).
the lua interpreter by itself is similar in scope to freestanding c. You can do anything, but you have to do everything. Lua doesn't come with much. Just some very basic file io (not even including listing files). Stuff that embeds lua is supposed to provide a runtime for lua programs to actually interact with.
As others have noted, this is not actually a Lua engine written in Rust. It is a wrapper over existing C/C++ implementations of Lua. There is, however, an actual Lua engine written in Rust. It is called piccolo.[0]
[0] https://github.com/kyren/piccolo
Misleading use of the term "runtime" as it does not implement lua, but just links nonrust implementations into a webserver "runtime."
Yep. Specifically, the crate uses mlua: https://github.com/ArkForgeLabs/Astra/blob/f812bb0dc2881d740...
That's exactly how the term runtime is consistently used in the JS world... not sure it's misleading at all. Certainly less exciting/ambitious than if the interpreter was also rewritten, but its what it says on the tin as I understand the words.
V8 and JSCore are a runtimes, everything else is made up stuff by people without background in compilers.
Not sure what this is. The homepage shows making an API in Lua. So is a web framework?
In any case, a bad description term-wise. Being referred to as runtime made sense for Node & JS, since JS was until Node mostly confined to web browsers with Node setting it free giving native OS access, an event loop, and even a module system. Lua, Python, etc are already shipping as their own self-contained runtime. So calling a Lua, Python, etc wrapper in X as runtime written in X makes no sense.
The "runtime" word is very confusing in this case.
It's a web application server written in Rust (Axum/Tokio), that has hooks into Lua bindings (mlua) so that application behaviors can be implemented in Lua.
The naming is definitely unfortunate, as I was briefly excited for a lua VM written in rust.
Anyway, for those who want a lua version of nodejs/bun/deno, try looking at https://luvit.io/ (lua) or https://lune-org.github.io/docs/ (luau - AKA roblox lua).
If you want a Lua webserver, the way to go imo is Redbean.
https://redbean.dev/
Based on CosmopolitanC with incredible performance and single binary runs on any platform.
There is also MakoServer.
https://makoserver.net/
More for embedded but runs in anything and also very batteries included, like Redbean including SQLite and JSON for example.
Not to be missed up with Astra, a Wordpress plugin.
https://wpastra.com/
Naming is hard.
The top claim is that it's "Incredibly Fast" but I can't find any performance benchmarks. Can anyone find a link?
It seems to just be re-exposing existing lua runtimes, which makes the naming very unfortunate IMO. The underlying runtime Luau, for example, details its performance here https://luau.org/performance . Luajit is already popular and has plenty of benchmarks online.
Looks neat. I built a programmable server for Server-Sent Events using a similar stack (Rust/mlua/axum) [1]. I think the Rust/Lua interop story is pretty good.
[1] https://github.com/benwilber/tinysse
Light-mode CSS is broken https://astra.arkforge.net/docs/latest/internals/structure.h...
(looks as if `code` words are redacted LOL)
How does it compare to LuaJIT? LuaJIT is super performant, that I know.
I transpiled Lua into wasm so that I can run in a browser. It has very little practical purpose, but I thought that it was kind of cool.
https://i.imgur.com/ErSNVoR.png
I don't know I think it could be useful. I did this a while ago:
https://github.com/nhatcher/ariana-lua
But next time I think I would like to have a language that compiles in the browser to wasm
"written in Rust"
ok
Correct me if I'm wrong, but it looks like this is using the mlua Rust bindings (which are excellent). It's not a Lua runtime from-scratch in Rust. It's the regular C Lua/LuaJIT with a Rust interface.
You're thinking of the interpreter, not the runtime. The runtime is libraries, not the interpreter. The async-io frameworks and stuff like that. Just like how node.js is a javascript runtime, it uses the V8 engine, and bun is also a javascript runtime that uses javascriptcore instead. Neither one of them wrote their own javascript interpreter.
I think of the runtime as the whole execution stack. The interpreter, engine, JIT etc. is the back end. The interface to the world is a wrapper around that.
I would describe this as a Lua wrapper written in Rust. That carries the clear indication that you should not expect the interpreter to be written in Rust.
I would be (and indeed was) disappointed to see that this 'Lua runtime' did not have a Rust implementation of Lua. I would be much more interested in seeing that than a wrapper.
100% of Lua?
It's a runtime, not a lua interpreter/jit.
The first sentence in its readme is the following: "Astra is a web server runtime for Lua (5.1-5.4), Luau and LuaJIT written in Rust with native support for Teal."
The interpreter/jit has traditionally been considered part of a dynamic language runtime, arguably the major part, before JS-brained companies started to call their every repackaging of V8/JSC a runtime (which is technically correct but only considering part of them is off-the-shelf).
> It's a runtime, not a lua interpreter/jit.
Would you say the Lua interpreter is also a Lua runtime?
the lua interpreter by itself is similar in scope to freestanding c. You can do anything, but you have to do everything. Lua doesn't come with much. Just some very basic file io (not even including listing files). Stuff that embeds lua is supposed to provide a runtime for lua programs to actually interact with.