You can now learn how Roto's integration with Rust works under the hood from the comfort of your own home (instead of a very crowded campus), because my FOSDEM talk has been published!
Props to the @fosdem team for publishing the videos so quickly! It's very impressive!
https://fosdem.org/2026/schedule/event/DS7LFX-rust-roto-calling-jit-compiled-scripts/
You can now learn how Roto's integration with Rust works under the hood from the comfort of your own home (instead of a very crowded campus), because my FOSDEM talk has been published!
Props to the @fosdem team for publishing the videos so quickly! It's very impressive!
https://fosdem.org/2026/schedule/event/DS7LFX-rust-roto-calling-jit-compiled-scripts/
We tagged version 0.10.0 of Roto!
For those who are unfamiliar: Roto is a statically-typed, compiled, embedded scripting language for Rust by @nlnetlabs.
You can view the full release notes on our forum: https://community.nlnetlabs.nl/t/release-roto-0-10-0/61.
I'll summarize the most important features in a thread!
1/8
We tagged version 0.10.0 of Roto!
For those who are unfamiliar: Roto is a statically-typed, compiled, embedded scripting language for Rust by @nlnetlabs.
You can view the full release notes on our forum: https://community.nlnetlabs.nl/t/release-roto-0-10-0/61.
I'll summarize the most important features in a thread!
1/8
The next version of @nlnetlabs 's scripting language Roto (to be released sometime in December) will include a much-requested feature: lists! Below is a small example of lists in action, showcasing how easy it is to pass them to and from a Roto script. It will print `Result: [0, 1, 2, 3, 4, 5]`.
I'd like to take a moment to explain why lists were so hard to include in Roto in a thread!
1/6
The next version of @nlnetlabs 's scripting language Roto (to be released sometime in December) will include a much-requested feature: lists! Below is a small example of lists in action, showcasing how easy it is to pass them to and from a Roto script. It will print `Result: [0, 1, 2, 3, 4, 5]`.
I'd like to take a moment to explain why lists were so hard to include in Roto in a thread!
1/6
roto - The strongly-typed, compiled #embedded scripting language for #Rust, used by Rotonda
Introducing #Roto: A Compiled Scripting Language for Rust (May 2025):
https://blog.nlnetlabs.nl/introducing-roto-a-compiled-scripting-language-for-rust/
Repo:
https://github.com/NLnetLabs/roto
This looks awesome! I love strongly typed scripting languages! 
And the fact that it integrates with Rust so seamlessly... ✨
#RustLang #ProgrammingLanguage #Scripting #ScriptingLanguage
roto - The strongly-typed, compiled #embedded scripting language for #Rust, used by Rotonda
Introducing #Roto: A Compiled Scripting Language for Rust (May 2025):
https://blog.nlnetlabs.nl/introducing-roto-a-compiled-scripting-language-for-rust/
Repo:
https://github.com/NLnetLabs/roto
This looks awesome! I love strongly typed scripting languages!
And the fact that it integrates with Rust so seamlessly... ✨
#RustLang #ProgrammingLanguage #Scripting #ScriptingLanguage
let asn = ASN
.as_asn_matcher()?
.lookup(request.header("x-forwarded-for"))
.to_string();
if BANNED_ASNS.matches(asn) {
return garbage("banned-asn");
}
Not ideal, due to having to convert an u32 to a string, and then match that string against a pattern (with AhoCorasick), but it gets the job done. As a first approximation, this is okay-ish, but I'll be iterating on this a bit more.
Another reason the previous ASN->string->AhoCorasick thing doesn't quite work is because the pattern matching is a partial match. Thankfully, there's a StringList type I export to #roto, with a .contents() method, so:
let asn = ASN
.as_asn_matcher()?
.lookup(request.header("x-forwarded-for"))
.to_string();
if BANNED_ASNS.contains(asn) {
return garbage("banned-asn");
}
...this will work correctly, though, it will be slower than an AhoCorasick match if the list is longer than about a dozen ASNs. And the string conversion is comparatively expensive.
I'm currently writing #Fennel examples, and this is delightful. I even managed to make the decide function even more beautiful than it was!
(local ruleset [is-in-ai-robots-txt?
default])
(fn decide [request]
(accumulate [outcome nil
_ f (ipairs ruleset)
&until (not= outcome nil)]
(f request)))
This is perfection.
From nothing to running iocaine + Caddy with ai.robots.txt's robots.json and a few metrics as a starting point.
Contains #Roto, #Lua, and #Fennel - and a few tests too, for each.
I'm on a bit of a roll lately, and have released #iocaine version 2.4.0 just a few moments ago.
This does not bring that many significant changes as 2.3.0 did, but it does introduce #Lua and #Fennel as languages you can script its decision making with, on top of #Roto, which was introduced in 2.2.0.
While these languages run slower than Roto, they're still very fast, and are not going to be a bottleneck - they do provide a more familiar language to write the decision making in!
Oh, and metrics can now be persisted across restarts.
"What is acceptable?", you may ask.
Well, anything faster than ~40k req/sec in release mode will do. Why ~40k req/sec? Because that's my reverse proxy's bottleneck.
I also expect a very naive implementation of return false to run at at least at 1k req/sec in release mode.
What's a naive implementation? Creating the runtime environment on every request, and compiling the trivial program on every request.
In other #iocaine news, I'm doing some final polishing on #Lua scripting support, to make it as convenient as #Roto.
Right now, there's a differenc between how Lua and Roto scripts are loaded: with Roto, one needs to give a path to a directory, and pkg.roto will be loaded from there, and any imports will be relative to that directory.
With Lua, one gives iocaine a file path, and - currently - needs to set up the package.path search path manually.
So here's what I'll do: I'll make iocaine require a directory for Lua too, and it will add it to package.path, and will require("main"). The required module will also have to return a table with at least a decide key, and an optional run_tests key. This will simplify finding the functions to run, and will greatly reduce the number of special cases.
Today, I'm writing tests. Originally, I planned to write a bunch of tests in Rust to exercise the request handlers, but that felt like a huge pain in the backside, and would've involved a lot of repetition and boilerplate.
Then, I figured: I'll write the tests in #Roto and #Lua! Test the things from that side. Much less boilerplate, but still a lot of repetition.
Instead, I'll be writing a test suite to verify the decisions of a request handler. I'll run it for both engines, #Roto and #Lua. I will still have to write the scripts twice, but I will only write the verification once.