Yes, I was missing a 'companion language' for Rust similar to Lua for C and C++, I tried Lua bindings and other Rusty scripting languages but felt like starting a new project would be worthwhile.
I can't imagine wanting a 2.0 release, I'd rather take longer to get to 1.0 to reduce the risk of needing it, and anyway I'd much prefer to aim for something like Rust's editions, allowing the language to evolve without the whole community needing to migrate.
Before 1.0 I'd want to address at least:
- the FFI / package management topics mentioned above
Limited for now, Koto's main role as an embedded language has meant that I haven't had a need, but I would like to provide bindings for other languages at some point, and to enable dynamically loaded Rust libraries.
I'd start by trying UniFFI [1] which looks much simpler than the approach of manually writing a C API and using that as a foundation for higher-level language bindings.
This would also likely be the starting point for a package management system (if there ends up being demand for one). Rust doesn't have a stable ABI so to make sure that dynamically loaded Rust packages are compatible, either Koto would need to be in the business of Rust toolchain management so that packages can be recompiled when needed, or an API layer would be needed. There are some projects that provide ABI-compatibility shims but I don't like the idea of having two separate approaches to FFI, so I'd want to try to build on the foreign-FFI layer once it's in place.
I'm half hoping that by the time I'm interested in working on this Rust will have decided to pursue ABI stability. And there's also something in the back of my mind that's yelling 'Wasm!' at me but I would need someone wiser to convince me that it would be the right direction.
In my tests it's been ~1.5-2x faster than Rhai, but Koto's still some way behind Lua in benchmarks so I'm not trying to make a big claim here (although that said one of the reasons I started work on Koto was to avoid the runtime overhead of Lua <-> Rust conversions, e.g. Koto shares the same string representation as Rust, Koto lists are just wrapped `Vec`s, etc).
What I've had in mind with Koto is that when I need strictness and precision I'll generally be using Rust, and Koto is more intended for another aspect of programming where I want things to be much more fluid and easy-going.
My thinking is that the potential footgun here is outweighed by the win of paren-free calls for quick scripting / rapid iteration, but it certainly counts towards the language strangeness budget [1] so I figured it was worth pointing out in the guide.
Yes I would certainly hope so, you shouldn't need to know any Rust if you want to learn Koto. The guide assumes that the reader has some general experience with programming, but not from using any specific language.
Yes that's right, they're checked at runtime (with the option to disable the checks if the performance cost is a concern) and failed checks simply throw exceptions.
The hints aren't used for other purposes at compile time yet, but they could enable some warnings.
I'm less conflicted about having music tools in the browser. Yes, it's less efficient, and there's more risk of dropouts, and there's less control over I/O, and there's generally less you can _do_... But what's emerging is widespread access to increasingly sophisticated music making tools, and I don't see a reason to want to slow that down?
I've been working on Koto which is intended for this kind of use case. I've been thinking about extending Rust applications with scripting, and I have games in mind but more generally I'm interested in rapid iteration in creative applications. It's still very early so I haven't shared it more widely but I'd be curious to hear what you think.
If it helps here's a git blame helper script I made for Helix (as an example of practical code without any effort put in to making it readable for others): https://github.com/irh/dotfiles/blob/main/scripts/.scripts/g...