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.
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.
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.
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.
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
Is this one of those things that claims to be fast purely by virtue of being written in rust?
Considering one of the project goals at the top of the readme is "Don't be obnoxiously slow" obviously not - it doesn't claim to be fast at all.
Misleading use of the term "runtime" as it does not implement lua, but just links nonrust implementations into a webserver "runtime."
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.
That's not at all what a runtime is, in any context, ever. Where else have you seen this solecism? It's new to me.
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.
> Where else have you seen this
Node.js is easily the most famous example. Also deno, bun, winterjs, and probably a bunch more.
Someone upthread just linked a bunch of other equivalent lua projects that also refer to themselves as runtimes: https://news.ycombinator.com/item?id=46036362
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.
V8 and JSCore are a runtimes, everything else is made up stuff by people without background in compilers.
Yep. Specifically, the crate uses mlua: https://github.com/ArkForgeLabs/Astra/blob/f812bb0dc2881d740...
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.
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.
I assume the relevant performance benchmarking would be of the http server APIs it exposes to lua, not lua itself.
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.
Redbean is very fun. I built a mini Markdown-based CMS with it earlier this year: https://github.com/kevinfiol/beancms
I have used luvit and I can recommend. I used it for my Discord bot written in Lua.
There seems to be quite a few of projects like this these days:
* https://github.com/Scythe-Technology/zune * https://github.com/lune-org/lune * https://github.com/luau-lang/lute * https://github.com/seal-runtime/seal
All slightly different. Personally, I like Lune and Zune. Have used both to play around and find them fun to use
I think luvit [1] by Tim Caswell was the first one I saw that got me excited many years ago. I love to see passion for Lua/Lua derivatives.
[1] https://github.com/luvit/luvit
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
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
Light-mode CSS is broken https://astra.arkforge.net/docs/latest/internals/structure.h...
(looks as if `code` words are redacted LOL)
Oh I missed that, thank you! Will open an issue for this
How does it compare to LuaJIT? LuaJIT is super performant, that I know.
It isn't a replacement for the LuaJIT. Rather a wrapper over it with Rust libraries being available for use. Batteries included essentially.
> Astra is a web server runtime for Lua (5.1-5.4), Luau and LuaJIT written in Rust with native support for Teal.
Seems like it is a web server runime only?
Hmm, the website is confusing because: https://astra.arkforge.net/docs/latest/std/serde.html
Although even on https://astra.arkforge.net/docs/latest/std/crypto.html it mentions it is for web servers. ("During development of your web servers [...]")
So ultimately it indeed is for webservers, and the utilities are, too.
> Rather a wrapper over it with Rust libraries being available for use. Batteries included essentially
Any Rust libraries? Are there code snippets for random Rust libraries unrelated to webservers?
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
I know, I am just saying even in the documentation it mentions that they are implemented because it is good / useful for web browsers.
You should totally implement BLAKE2b and ChaCha20. FWIW, BLAKE3 is in Rust already.
Additionally, these features seem to be highly related to web servers, IMO. Not exclusively so, but still.
"written in Rust"
ok
[flagged]
I don't see any reference to `0xiDizEd` in the docs or on github. Are you sure that you're discussing the right project?
Not to be missed up with Astra, a Wordpress plugin.
https://wpastra.com/
Naming is hard.
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
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.
> Lua doesn't come with much. Just some very basic file io (not even including listing files)
Don’t most people simply use the LuaFileSystem library for that? https://github.com/lunarmodules/luafilesystem
I think you (and the project) are using “runtime” when what you really mean environment.
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.
[dead]
[flagged]
This would be a best seller. HN without Rust and AI, thats the golden braid.
As I remember, you can just use ublock origin and some cosmetic filter with :has-text() or something.
If you’re not interested, don’t click it. But please don’t come to the comment section and write multiple comments complaining about its existence.
[flagged]
[flagged]
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.
[flagged]