Comment by ori_b
3 months ago
This language looks a lot like Rust. Why not dlopen() a Rust shared library instead? The implementation would be about as complicated, but it would be a well known language that's fully integrated with a large library ecosystem, well defined build and package set, rather than some custom one-off thing with no ecosystem. Going your own way means your users have to re-invent the wheel for themselves every time.
With Rust's safety, it's not even that bad to re-open and re-load the binary when it changes; the big footgun with dlopen is use-after-free.
Hi! Author here. There's a couple of reasons.
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.
Are you saying Roto has no ambitions to be suitable as a gamedev scripting language?
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).
4 replies →
Don't rust shared libraries have the problem of no stable rust ABI? So you either use the C ABI or you use some crate to create a stable rust ABI, because otherwise a shared lib compiled with rust compiler 1.x.y on system a isn't guaranteed to work with the binary compiled on the same system with another compiler... or on another system with the same compiler version.
Right?
You'd have a plugin layer that hooks in the right places with a stable ABI on one end, and a native feeling interface on the other.