irh

Haha well I'm sure if you put your mind to it you could create some madness in Koto!

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

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.

Yes that's essentially where it started, although it feels quite different to use now.

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

- async support: https://github.com/koto-lang/koto/issues/277

- extend the parser to support an autoformatter: https://github.com/koto-lang/koto/issues/286

...and then have a larger number of people using it in projects without major issues coming up for a good while, e.g. a year+.

Koto's dynamically typed, but optional type checks were introduced in 0.15: https://koto.dev/docs/0.15/language/#type-checks

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.

[1] https://github.com/mozilla/uniffi-rs

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.

[1] https://steveklabnik.com/writing/the-language-strangeness-bu...

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.

https://koto.dev/docs/next/language/

Yes! I'm using it for adding commands to Helix.

e.g. https://github.com/irh/dotfiles/blob/main/scripts/.scripts/t...

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.

Yes it's named after the instrument, although I'm happy to hear about the Italo disco connection =)

Koto creator here, nice surprise to see this on HN so I'm a bit late to the discussion. Happy to answer any questions!

Support for >8 channels led me to use WavPack instead of FLAC.

> Roli (the company selling JUCE)

I know it's tangential to the point that you're making, but JUCE was acquired by PACE in 2020.

Agreed, outstanding!

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?

Pre-omicron the vaccines were significantly slowing the spread of the disease. Post-omicron boosters are required to reach similar efficacy.

"100% of the 1%" is less nuanced than "99%".

It's already switched on nightly.

https://github.com/rust-lang/cargo/pull/9298

https://doc.rust-lang.org/nightly/cargo/reference/profiles.h...

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.

https://github.com/koto-lang/koto

Rust's macros aren't hacky though? I would understand this point better if you were talking about C's macros, but macros in Rust are hygienic so don't suffer the same pitfalls.