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.
First sentence of the Wikipedia article for Node.js:
> Node.js is a cross-platform, open-source JavaScript runtime environment that can run on Windows, Linux, Unix, macOS, and more.
First sentence for the Wikipedia article Deno:
> Deno is a runtime for JavaScript, TypeScript, and WebAssembly that is based on the V8 JavaScript engine and the Rust programming language.
First line of hero text from Node.js's site:
> Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts.
First line of hero text from Deno's site:
> Deno is the open-source JavaScript runtime for the modern web.
I've also seen discussions where wrapping the servo-browser-engine in a UI layer referred to the UI layer as a runtime, though I think that's a substantially less canonical use of the word than referring to the part of an implementation that takes requests from the interpreter and executes them in the surrounding environment as a runtime.
Author of Astra here, loved seeing all the responses here. It wasn't planned to be anything beyond internal usage, but you are correct that I should have been more clear on the description and naming. In any case, it is far from production level.
For those wondering, it is not a Lua implementation, rather wrapping over available Rust crates with Lua bindings and packaging everything into a single binary to be used. It is the way it is because our CI was spending a lot of time compiling our Rust servers, so this was made to speed up development for simple to mid complexity servers. And since then grew to have more functionality.
Naming wise it is true that it is confusing with Astro and other similar naming projects I agree. Name suggestions are welcome!
I have created an issue https://github.com/ArkForgeLabs/Astra/issues/121 to track all the arguments said here. Let me know if theres anything else I should look into. Thank you all for your feedback.
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.
While I agree it is not in the technical terms a runtime, the inspiration for it was from BunJS and Deno and such. Similar projects in the Lua space also name themselves as runtime, so I wrote runtime as well. It is not exclusively for web, although it started as that. Nowadays Astra has libraries for many general things, and are used in a wide range of projects, from scripting, CI/CD, API servers, and more.
Lua does ship a runtime, although it is incredibly limited in standard library, and lacks a lot of features that other languages ship out of the box. I could have either made a library to be used with each Lua VM or package everything into a single binary which was what we needed for our use case anyways, and gave a lot of control for us as well.
In any case, I agree that I should have been more clear in the description. It has not been updated since a while and the project moves very fast.
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.
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.
You are correct on this, I should have been more clear about the description. When I wrote the description I was in the headspace of BunJS and Deno. I will make note of this and write a better README description.
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.
I am stating it can be, and already is, used for other tasks, not just web servers. Although the server and networking cases were originally what it was built for and the plans were stay there.
Not "any" Rust library, the idea is to not reinvent the already made libraries out there for the use cases of the standard library, and rather make an interop with Lua. I am not sure what would count as unrelated to webservers but there are file system, templating, database, cryptography (minimal at the moment), serialization and deserialization moudles, with upcoming compression, logging, testing, and more coming soon https://github.com/ArkForgeLabs/Astra/issues/114
hahaha it really is. Astro is another project that it also clashes with. When I was naming it, I was thinking of Warhammer's Astra Millitarum. But I forgot that it is a very popular name in general... my bad
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.
Yes most do. But that is not part of lua. That is just a library one can load. It's written in C. The lua interpreter does not allow any access to the outside world.
That rudimentary "built-in" io that's included with lua? It's actually a library shipped with the interpreter, that you need to explicitly load in from the C side of things.
Exiting with a process exit code? Optional library.
String operations such as pattern matching? Optional library.
Math? Optional library.
Debugging? Optional library.
If you didn't load any of these, then the only I/O you could do is to stdout with the print statement. When you instantiate a new lua state, you are expected to provide your own runtime. It's a language designed to be embedded in other software.
Take, for example, libc. It's the C runtime. It doesn't compile or interpret C. libc is just a bunch of C code (with assembly sprinkled in, of course).
Or it could be that you posted an insubstansive comment that added little to the conversation. I don't use Rust. I certainly don't advocate for it, but I don't mind seeing posts about things people have done in Rust. I also don't use Lisp or Forth. I'd be quite interested to see people posting new projects that do real world things with those. Seeing languages being used helps you see what tools are the right ones for the job.
[0] https://github.com/kyren/piccolo