Hacker News Reader

Comment by ori_b | Hacker News Reader

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.

View on HN

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).

Having not yet actually tried it, I assume I could compile at startup on a separate thread with no issues? This seems like a dream scripting language--or "application language" as someone else called it.

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!

Thank you for putting this out there! I'll make sure to let you know what I think when I try it out—but I have some wood to chop on other parts of my app before I get into scripting.

Re: lists and loops, is that not supported because it hasn't been a priority or because it requires some fundamental redesign? Which is to say, if I wanted to add those down the road, is this something I could try my hand at implementing on my own and possibly contributing back?

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.

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.

Reply on news.ycombinator.com