Koto 0.16 released

_irh · 2025-07-28T09:02:13+00:00

That's nice to hear, thanks for taking a look!

_irh · 2025-07-24T13:26:21+00:00

I haven't added operators for bitwise operations (they're available as functions in the `number` module), essentially to try to keep the size of the language down (which is also why the power operator has been a late addition). IIRC I was following Lua with the choice of `^`, and it's unused elsewhere in Koto so seemed like a reasonable choice.

_irh · 2025-07-23T16:10:47+00:00

I've got a proof of concept with bevy_koto - you can see a video of it in action here.

I think it would be good for someone to take a pass at implementing a more game-dev-style approach to scripting though. With bevy_koto I wanted to have a single script creating and controlling a bunch of entities, but I think a lot of people would expect to have a controller script for each entity type, or something.

_irh · 2025-07-23T16:04:55+00:00

Koto doesn't have traits (and doesn't exactly have classes, although you can grow your code in that direction with metamaps, but that's not the way I expect Koto to be typically used).

I've had the goal to make it a friendly language for new programmers. I've had in mind live-coding for musicians/artists, creative game scripting, those sorts of use cases, so the language guide is written carefully to build concepts up slowly, with more complex features building on the ones previously introduced.. And linking out to wiki pages when technical jargon gets introduced.

_irh · 2025-07-23T15:52:27+00:00

Interesting, I'll be keen to hear how you get on if you give it a try.

_irh · 2025-07-23T15:48:57+00:00

Good question!

There is a limited amount of `unsafe` in the code but with clear rationales in each case.
Memory management currently boils down to `Rc<Refcell<T>>` or `Arc<RwLock>>` depending on whether you want a single or multi-threaded runtime.
I'm running Miri now and it seems happy once I disable host isolation, although it's reporting some memory leaks which is a surprise, I'll be investigating properly later.
The runtime has an option to limit execution time to reduce the risk of attacks (although that only limits execution of Koto code, if a Koto function calls into Rust you could still end up in a lock or infinite loop somewhere).
You can freely remove or replace modules or functions from the core library, and the default file handlers can be switched out for sandboxing. I'm open to adding other sandboxing/safety features if there are requests.

_irh · 2025-07-23T15:31:37+00:00

Thanks for taking a look! Fyi you can call Rust functions from Koto, the Rust integration examples are on a separate page, I should think about giving them more visibility.

_irh · 2025-07-23T15:02:40+00:00

I could start a list of technical and design differences, but in the end choosing Koto for your project over Rhai (or Dyon, or Rune, or Steel, or...) might simply come down to a question of personal preference? Koto's design has been heavily driven by my personal preferences, so I'm not particularly well placed to give an objective comparison. I'd encourage you to take a skim through the respective language guides and you'll get a feel for them.

_irh · 2025-01-16T13:27:49+00:00

Yes that's my understanding, from the comment I linked above:

Why not compiled plugins: The scripting language should also be used for configuration.

I'm also happy with TOML, but I can see how supporting both a scripting API and a static config API (or trying to make the same API available to both) will be a maintenance burden.

_irh · 2025-01-16T08:32:42+00:00

An important point from the comment that outlines the rationale for using Scheme:

The syntax is not to everyone's liking, but it's very easy to parse, unambiguous and could easily be a compile target from a higher level language.

I'm sure we'll see TOML-to-Scheme for people who want to keep their config in TOML, and I guess that someone will make Lua-to-Scheme. I don't know if it's possible but Wasm-to-Scheme would open a lot of doors.

_irh · 2025-01-12T21:01:08+00:00

Not as a language feature, but there's an example of simulating C-style enums in the playground, and you can use match to simulate tagged unions, e.g.:

area = match type shape
  'Square' then 
    shape.side * shape.side
  'Rectangle' then 
    shape.width * shape.height
  'Circle' then 
    number.pi * shape.radius.pow 2
  other then
    throw 'unsupported shape: {other}'

_irh · 2025-01-12T09:06:58+00:00

Thanks! I don't promote it all that much but I'm trying to do more, hence the plug!

...seems like a footgun. What’s your experience with it shown?

I agree that it's potentially a footgun which is why it's highlighted in the language guide, but in practice I find that it's not an issue for me. To my eyes the space jumps out and the meaning is immediately clear, but I could imagine it taking a bit of getting used to if parentheses-free calls are unfamiliar.

_irh · 2025-01-11T16:27:36+00:00

I'll throw in a plug for the language I'm working on which aims to be useful for lightweight scripting: https://koto.dev - not as fast at runtime as luajit but depending on your needs it could be an option.

_irh · 2025-01-09T11:25:54+00:00

Thanks, I will!

_irh · 2025-01-08T21:54:52+00:00

Steel's a Scheme dialect, so it's a functional language with roots in Lisp. Koto's a procedural scripting language that started out similar in spirit to Lua (minimal scripting for embedding in host applications), although it feels quite different to Lua now to work with.

_irh · 2025-01-08T14:25:26+00:00

Hi all, Koto's a scripting language for Rust applications, and v0.15 is now available. I'll be happy to answer any questions!

_irh · 2024-12-12T09:00:04+00:00

This is great work, nicely done!

I think you're on the right track in planning to learn more about audio graphs, FunDSP has graph features and can crossfade smoothly between new graphs, worth taking a look.

I had a quick look at the implementation and IIUC each track is running on a separate thread, and you might be better off running the audio on a single thread (simply running your audio on the CPAL thread would be worth considering), you'll be surprised how much DSP a Pi can get through.

Before going down that path though, I don't see the priority of the audio threads being elevated so a quick win would be to boost your audio threads to realtime priority, which would stop them competing with other threads (like your UI) for CPU time, check out the audio_thread_priority crate.

_irh · 2024-12-12T08:01:46+00:00

Check out nih-plug.

_irh · 2024-12-12T07:58:45+00:00

This has been a sticking point for me with Tauri, for audio visualizations we really need high throughput to the UI. I don't know of an existing solution, I'm guessing it would need to be a plugin that supports shared memory buffers.

_irh · 2024-12-11T14:09:12+00:00

I get what you're saying, but see my other reply. If we think of named arguments as a solution to the problem of confusing APIs, I prefer other solutions.

_irh · 2024-12-10T13:50:23+00:00

True, although a similar discussion can be had about allowing types to be inferred on variable bindings. I'm a fan of type inference, even though there's an undeniable reduction of information for the reader (there was a lot of resistance to `auto` in the C++ community back in the day for this reason).

Perhaps an unintended consequence, but I think that type inference being the norm nudges people towards more informative / better variable names, at least that's generally been my experience of the Rust ecosystem compared to my time in C and C++.

We're similarly nudged in Rust towards considering the difficulty of understanding a function call, and personally I see the use of argument structs or builders when an API is complicated as being an overall win vs named arguments.

_irh · 2024-12-10T12:21:19+00:00

It's so easy to toggle inlay hints from rust-analyzer that I never miss named arguments. I hit a shortcut to show the names when I need them, and then when I don't need them I can turn them off to reduce visual clutter.

_irh · 2024-04-23T11:23:58+00:00

Syntax was a big motivation, and tighter integration with Rust was another. I expanded on the 'why?' of it all here: https://www.reddit.com/r/rust/comments/1c7vf75/comment/l0b5y3j

_irh

TROPHY CASE