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.
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 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.
Would you say Koto (or some direct competitors, for that matter), is viable to learn when I otherwise don't intend to learn Rust at all? But let's say, want to keep the option open to participate in Rust-based projects which support Koto et al.?
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.
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.
Sorry, I meant the Koto language and built-in library compatibility story. Whats on the roadmap for a 1.0 and will you allow a 2.0? One of my annoyances with Tcl and Lua is their breaking changes would be pushed into my application and I'd have to decide what version of the language to target and have a plan for changing it.
I'm fine with the Rust API breaking compatibility.
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
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...