terts
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.
The `#cidr{...}` syntax would work but then it wouldn't be much more convenient than just constructing the value with normal functions, I think.
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.
> 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)
> sum_scalar (counter): 28.56ms > sum_list (List[u64]): 590.48ms > -> 21x slower
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.
So it should probably say "Roto _in Rotonda_ does not have loops". Roto the language as a separate project can then have loops.
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.
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.
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.
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.
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.
Hope that answers your question!
uutils can behave as a busybox-like binary. But I think there's some confusion over the requested feature, because that can't really be done with regex, but you have to inspect the file metadata to check the type of file. That's also why a grep solution doesn't really work, unless you use `ls --classify` and then use the indicators to filter in `grep`.
> if we are talking about separate binaries adding it to `ls` makes it bigger for everyone, even for those who will never use this feature
It's generally not these kinds of features that increase the binary size, but if it does we could also introduce feature flags for it, where you can choose at compile time whether you want the uutils extensions or not. It still adds a bit of a maintenance burden of course.
We tend to do this sparingly, however, because even just adding new flags might break existing scripts that use abbreviated long options. For example, if the flag you propose is called `--filter` it might break scripts that use `--fi` as a shorthand for `--file-type`, because the prefix is now ambiguous.
I personally like the flag you propose!