This is something we've been backpedaling a bit indeed. 0.11 changed some things to look a lot more like Rust. The reason for this being different in the first place is that were not trying to make Rust-but-simpler necessarily. Or target audience with Rotonda is also not Rust programmers. So we've been exploring different syntax options.
Regarding the List type, as we optimize that, it will probably become a different data structure from a Vec. Also in the Roto-Rust boundary, you cannot pass in a normal Vec. So different names male sense there.
Regarding the case, small primitive types are lowercase. String and List are heap allocated and therefore somewhat different. I'm open to changing that but there is some logic to it.
That's kind of right, but they are adding new literals, not changing existing ones. The hooks are for the lexer and they can decide what syntax they accept. The syntax it defines would be a parse error if the hook is not used. But, indeed, this can be misused by accepting too much though, for instance when an IP addr also accepts a float. So the hook needs to be a bit careful.
The `#cidr{...}` syntax would work but then it wouldn't be much more convenient than just constructing the value with normal functions, I think.
Other commenters have given most of the reasons already, but since you asked specifically for the author, I'll chime in as well.
The fact that Roto gets compiled at the runtime of the Rust application is very important. That means we can ship a binary and still allow scripting.
We also believe that Rust is too complicated for our use case in some respects, we're trying to make something simpler. Our target audience for Rotonda is not people who necessarily know Rust. We can never be as simple as Lua because of the static typing, but we're trying our best.
And finally, we don't have to ship the entire Rust toolchain with our application. Roto is fully embedded into the binary with no external libraries needed and that's quite nice in practice.
Hi! Author here. You're looking at Rust code there. Roto is very similar but without `&`. I wont pretend to be good at language design, but being similar to Rust has many advantages.
> When you made Roto what kind of workloads were you optimizing for?
We're building a BGP collector with custom filters written in Roto. Imagine a database that constantly receives updates and we want to filter (or transform) those messages based on a script.
> How are you guys benchmarking performance?
Actually, we haven't done that much as feature work has been more important than optimization. There's a lot of opportunities for optimization left on the table.
There are a few benchmarks that we have done:
- A very naive fibonacci computation, where we were faster than Lua,
- There's this benchmark with a lot of string manipulation made by somebody else where we roughly match Lua: https://github.com/khvzak/script-bench-rs
- There's the testing done with Iocaine, where Roto is apparently much faster than Lua. The scripts there do a lot of inspection of fairly simple types.
So the nuanced take is that Roto is fast with numbers and other cases which don't involve complex data structures that some other languages have really optimized for.
> I'm happy to cut a PR against your repo with some of the benchmarks I run on every commit in my own language projects if that would be helpful!
That would be very helpful! A proper benchmark suite is long overdue. (but do note that we don't accept AI contributions)
I think the list is so much slower it's calling out to Rust a lot to get items from the list. Lists currently also have a mutex inside, which would need to be locked for each access.
Hi! Author here. What we call the `Runtime` in Roto is not a state of the program, it's only the set of functions, types and constants that are available to the script. Roto scripts cannot really keep state at the moment. The advantage of that is that it allows you to run scripts in parallel. We're thinking about how we can keep that property while also having some state.
Hi! Author here. We are actually planning on removing those literals and allowing applications to extend Roto with their own literals [0]. They should do so with care of course, because indeed adding more literals adds some edge cases. Most applications should be able to get by without any special literals though.
Hi! That bit of the docs is a bit outdated. We're probably gonna make it optional. The reason for that choice was that the filters for Rotonda need to be very quick and don't really require loops as long as you can do `contains` checks on some lists for example.
So it should probably say "Roto _in Rotonda_ does not have loops". Roto the language as a separate project can then have loops.
Hi! Author here. You could try but there are some fundamental limitations.
The biggest limitation is that we don't have access to the full type system of Rust. I don't think we can ever support registering generic types (e.g. you can register `Vec<u32>` but not `Vec<T>`) and you don't have access to traits. So it would work if you can reduce your API to concrete types.
Otherwise - apart from some missing features - you could probably write big chunks in Roto if you wanted to. You could also prototype things in Roto and then translate to Rust with some simplified types.
Also you'd have to accept that it gets compiled at runtime.
They're on the roadmap for sure. While loops are quite easy to add I think, but it would also need an assignment operator to make it useful. Lists are complicated because they're generic over the element type. That's why I've waited so long to add them.
Yes, you definitely could! And thanks for the kind words! If you try it out for your own purposes, you'll probably run into some missing features (e.g. lists and loops), but we'd be happy to hear what you think!
It depends. I'd love to make a prototype using Bevy with Roto. What I'm trying to say is that if you only want something to make Rust compile faster, then Rust might the better option. If you want something that behaves more like a scripting language and you don't mind that is compiled at startup, then Roto might be good for that purpose (with the caveat that there are missing features of course).
Hi! Author here. Mun is super cool, but works slightly differently as far as I know. You compile Mun scripts outside of your application to a dynamic library, which can then be (re)loaded by your application. The advantage of that approach is that you can ship the compiled script with your application.
The downside is that it's not really possible to share types between the host application and the script as far as I know. They have something called called `StructRef` which does this a bit, but it's all runtime checks if I understand correctly.
If somebody here knows more about Mun, I'd be happy to be corrected. This is just my understanding from their documentation.
Hi! Author here. Would be super cool, but while the compiled scripts would work without allocations, the compiler itself does a lot of allocations. So unfortunately I don't think I could make that work.
First, this language is syntactically a lot like Rust but semantically quite different. It has no references for example. We're trying to keep it simpler than Rust for our users.
Second, using Rust would require compiling the script with a Rust compiler, which you'd then have to install alongside the application. Roto can be fully compiled by the host application.
I think your approach might be preferred when the application author is also the script author. For example, if you're a game developer who is using a script to quickly prototype a game.
Not many iterations, but a lot of head scratching was involved haha.
I decided against using a trait and a derive macro because I wanted to avoid running into Rust's orphan rule. We have a crate called routecore where most of our types are declared and then a separate crate called Rotonda which uses those types and uses Roto. I wanted Rotonda to be able to register routecore types.
That's also the downside of the current reflection crates; they require each type to have a derive macro.
Hi! So for Roto, our introspection needs are actually fairly limited. We only need the `TypeId`, the type name, the size and the alignment. which Rust can give us without any additional traits. It's not possible currently to - for example - access struct fields and enum variants. That is something that I plan to add, but that might require a crate like `bevy_reflect` or `facet`.
Rust is giving me just enough information to pull the current version of. More powerful introspection/reflection is not possible without derive macros. If you're ok with derive macros though, you could look into the 2 crates I mentioned.
Regarding the List type, as we optimize that, it will probably become a different data structure from a Vec. Also in the Roto-Rust boundary, you cannot pass in a normal Vec. So different names male sense there.
Regarding the case, small primitive types are lowercase. String and List are heap allocated and therefore somewhat different. I'm open to changing that but there is some logic to it.