I hate TS's tooling with a burning, deep passion. But its type system is actually pretty incredible for what it is.
There are times that I yearn for TS's ability to do duck type reasoning in e.g. Rust (despite that not being feasible) when working with very large data types.
On the other hand, if the same problem keeps happening, it's hard to argue that the problem isn't foundational to the design and that it should be called out until either the problem is fixed or the design abandoned.
It's not that there isn't a conversation to be had. It's that it's a low-effort, karma farming, reddit-tier comment that always invites emotional/reactionary responses, typically the same ones as before, that usually shoots to the top of the comments section and drowns out any relevant or interesting (see: curious, as per HN guidelines) discussion.
The syntax is of course very Rusty, which is cool. However, a sort of obvious question comes to mind - what is the benefit of this over just writing rust, then? Just because the compile times are shorter?
EDIT: should mention I understand why embedded scripting languages exist, having embedded Lua many times. And I love a lot of these features, but to me having an embedded scripting language should simplify the language/API surface area instead of mirroring it almost 1:1. That's what I'm a bit undersold on.
I'm author of a rust based task manager (not (yet) FLOSS, unfortunately), where we needed "pluggable task sources" (jira, github, trello, etc).
In our setup, the "sources" are more like configuration. Whereas the core, the business logic, is more like code.
Typically, one would configure with e.g. YAML. As we can see in many projects, that have a DSL, in yaml (k9s, GitHub actions, ansible, etc).
But, rather than inventing another DSL in yaml, we realized we do need some logic, something very poorly expressed in yaml. And we went for Lua.
Long story to say: if your config typically has some logic in it, it makes sense to go for an embedded scripting language to provide it, rather than building it into the core domain, or to invent yet-another-yaml-amalgation (yayamla?)
Hot-reloading. You can edit your logic without rebuilding and restarting the host application; this cuts your iteration time from minutes to seconds, especially if the application is in a state that would need to be recreated.
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.
Well something needs to be done urgently, before hospitals and critical infrastructure start getting ransomware infected on a daily basis. This isn't an unlikely scenario either, all it will take is one well resourced attacker to spin up thousands of decensored agents and have them pumping out attacks 24/7. I'm actually kind of surprised it hasn't already happened. TeamPCP is just the beginning. We're lucky they're not using ransomware, otherwise the carnage would be 100-fold.
Then the corporations, medical system, etc needs to help support the people who make OSS software if they want the immediate, urgent change you're suggesting.
Those are individual revenue streams, distributed at a very granular level across the world.
LLMs are currently relegated to individual for-profit companies. They collect that money. There's no other choice to use them and to provide them that money.
reply