Dyon: dynamic scripting for Rust applications

Dyon targets configurable Rust applications

Dyon addresses a specific boundary between a host application built in Rust and logic that is easier to change, expose, or generate as source code. The repository describes it as a dynamically typed scripting language, and its feature set is aimed at developers who want more than a fixed configuration parser. Dyon programs can define functions, construct arrays and objects, call host functions, load modules, work with option and result values, and start coroutines. That makes it relevant to command-line tools, extensible applications, game-related systems, and other Rust programs that need a programmable layer.

The repository does not present Dyon as a general replacement for statically typed application code. Instead, it documents a lifetime checker, a mutability checker, runtime mutation checks, optional type signatures, simple refinement types, and ad-hoc types. This is a middle ground between dynamic execution and selected interface checks. The exact scope of those checks is not described in the README, so an adopter should not treat the feature names as proof of static guarantees comparable to Rust's own type system.

Dyon is written primarily in Rust and distributed as the `dyon` crate. It can be used through command-line programs, but it also supports Rust embedding through `Module`, `dyon_fn!`, dynamic module loading, and custom Rust objects based on `Arc<Mutex<Any>>`. The intended users are therefore both people writing `.dyon` files and Rust developers deciding how to expose an application API to scripts.

Dyon moves values through modules and host functions

A Dyon script file uses the `.dyon` extension and follows a compact expression-oriented syntax. Its values include `f64` numbers, booleans, arrays, objects, options, results, functions, and links. Arrays support indexed lookup, while objects permit field insertion and mutation. Function declarations can return a value or have no return value. Dyon also permits functions as mathematical expressions, closures, coroutines, and module imports.

Dynamic loading is the main execution boundary visible in the README. A script can load another file through `load("script.dyon")`, unwrap the returned module, and invoke a named function such as `main`. The loader can also receive imports, making selected module values available in the script prelude. In a Rust host, `Module::add` registers custom functions, while the `dyon_fn!` macro can define a function that is callable from Dyon.

Error handling is represented directly in the language. Option values use `some(x)` or `none()`, or `ok(x)` and `err(x)` as results. The `?` operator propagates an error, and `unwrap(x)` prints the trace of a propagated error. This gives scripts a visible path for partial failure instead of requiring every host operation to be reduced to a boolean. However, the README does not document exception hierarchies, stable error schemas, or a rollback mechanism, so consumers that need machine-readable, versioned error contracts would need to inspect `DYON-API.md` and the implementation.

Concurrency is also part of the language rather than an external addon. `go foo()` starts a coroutine, while `in` values and `for x in a` support channel-style communication. These features may fit simulation or event-driven code. They also mean the host must account for threading, shared objects, synchronization, and the optional `tokio` dependency when selecting features.

Installing Dyon and running the first script

The README gives separate installation commands for the REPL and the standalone script runner. These install example binaries from the `dyon` crate with Cargo. Run the installation commands in an environment where Cargo is already available.

Install the interactive REPL:

cargo install --example dyon dyon

Start the REPL after installation:

dyon

Install the command-line runner:

cargo install --example dyonrun dyon

The README's introductory program prints `hello world!` from a function named `main`. Save it as a file ending in `.dyon`, then invoke the installed runner with that filename. The runner command takes the script path as its positional argument.

fn main() {
    println("hello world!")
}

dyonrun <file.dyon>

The expected result of the introductory program is the line `hello world!`, based on the README example. The repository also exposes an interactive implementation under `interactive/`, and its editor integrations include Dyon packages for Atom, Vim, and Visual Studio Code. The README links to those projects, but it does not give installation commands for them.

For development through Rust rather than the standalone runner, the repository includes examples such as `examples/functions.rs`, `examples/run_str.rs`, and `examples/call.rs`. The README specifically links `examples/functions.rs` as the location for the `dyon_fn!` embedding macro. It does not document a stable high-level command for creating an application project, so host integration requires following the crate API rather than treating `dyonrun` as an SDK installer.

Default Cargo features widen the embedding surface

The `Cargo.toml` file declares Dyon version `0.51.3`, Rust edition `2024`, and the license expression `Apache-2.0 OR MIT`. Its default feature set is `debug_lookup`, `dynload`, `file`, `http`, `stdio`, `threading`, and `rand`. The optional `async` feature enables `tokio`.

That list materially affects adoption. A host that enables defaults receives more than a syntax parser. Dynamic loading permits scripts to load modules, file and stdio features expose host resources, HTTP depends on `reqwest`, threading supports concurrent execution, and `rand` brings random-number support. This can reduce assembly work for an extensible application, but it also expands the dependency and permission surface that the host application inherits. The repository does not document a minimal configuration for a sandboxed script runtime, so the README and `DYON-API.md` should be checked before exposing dynamic loading or filesystem access to untrusted scripts.

The project is not archived, and the last push was on 2026-09-12. That indicates recent repository activity, but the listed recent releases are `v0.36` from 2018-06-16, `v0.9` from 2016-09-19, and `v0.8` from 2016-07-11. The package manifest names `0.51.3`, so release tags and crate versioning should not be assumed to match. Consumers should check the exact crate revision they depend on and avoid assuming that the older tags describe today's API.

Choosing between the REPL, runner, and Rust embedding

For a new user, the clearest choices inside this project are Dyon-Interactive, `dyonrun`, and Rust embedding. The REPL is intended for interactive work and is installed as the `dyon` example. `dyonrun` is intended for files and receives a `.dyon` path on the command line. The first approach shortens the edit and execute loop. The second is more appropriate for repeatable scripts that need a clear input file.

Rust embedding follows a different approach. Instead of treating a script as a standalone command, the host creates or manages a module, registers functions with `Module::add`, and exposes selected objects through Dyon values. A macro can simplify function declaration for embedded use. This is preferable when the script needs direct access to host capabilities. It also moves more responsibility into the Rust application, including module construction, function registration, and the permissions associated with enabled features.

Dyon offers optional type declarations, so a team must decide whether scripts should remain entirely dynamic or use signatures such as optional array types and return types. Dynamic values provide flexibility, while signatures may catch some interface mistakes before execution. The trade-off is that Dyon is not documented as a fully static language, and runtime values can still cross boundaries. A team needing stronger static guarantees would have to establish its own restrictions, but the repository does not describe such a policy framework. For the same reason, Dyon is a poor substitute for a language selected primarily for formal static typing.

Dyon license and runtime boundaries

Dyon is offered under `Apache-2.0 OR MIT`, as stated in `Cargo.toml`, and the repository contains `LICENSE-APACHE` and `LICENSE-MIT`. That is a permissive dual-license choice, but the repository material does not provide legal interpretation. The host organization must check which license terms it needs to satisfy, including notice and attribution requirements, before distributing an application.

The license does not remove the need to inspect runtime capabilities. `dynload`, `file`, `stdio`, `http`, `threading`, and `rand` are enabled by default in the manifest. If scripts can be supplied by users or other systems, the host must decide whether those capabilities are acceptable. The README documents loading, custom functions, coroutines, and Rust objects, but it does not define a sandbox, resource quota, permission prompt, or safe execution boundary. That absence is a meaningful limitation for multi-tenant or untrusted-script use cases.

Release planning also deserves attention. The repository is not archived and its last push was on 2026-09-12, yet the listed releases stop at `v0.36` in 2018. The manifest's `0.51.3` version indicates a different current package line, but no release policy or upgrade procedure is included in the available documentation. Consumers should therefore verify the exact crate revision they depend on and avoid assuming that the older tags describe today's API.

Editorial conclusion

Adopt Dyon when a Rust application needs user-facing scripts and can accept a dynamically typed runtime. Do not choose it for a conventional static type system or a documented sandboxing model. Before adoption, verify compatibility with the intended Rust toolchain, exercise dynamic loading and threading with default features, and confirm that the optional type checks meet the application's safety requirements. The decisive issue is whether embedding `dyon` and its default feature set fits the host application, not the breadth of its scripting syntax.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. PistonDevelopers/dyon on GitHub
4. README
5. Releases