embedded-scripting-languages: Choosing an Embeddable Interpreter

A Catalog for Host Application Scripting

dbohdan/embedded-scripting-languages addresses a selection problem rather than a runtime problem. It collects open source embedded scripting languages that application developers can consider when scripts need to execute inside a native program. The README also includes Datalog implementations, deliberately stretching its definition of an embedded scripting language. This broad scope makes the repository useful for initial research, but it also means that entries are not interchangeable products. A C interpreter, a C++ header-only library, a Go implementation, and a JVM-hosted project expose different integration assumptions.

The catalog includes AngelScript, CEL implementations, Datalog runtimes, and many other entries. It records the implementation language, garbage collection approach, and software license for each entry. Those fields allow developers to eliminate unsuitable candidates quickly. For example, a project can reject an implementation written in another language when it must be linked into a constrained native binary, or investigate an implementation with no garbage collector when predictable memory release matters.

The intended user is an application developer choosing an interpreter library, not an end user looking for a command-line scripting environment. The catalog does not implement an API, resolve dependencies, or provide a common embedding interface. Selecting an entry is therefore only the first step. The README describes candidates as "reasonably mature or actively developed," but it does not define a maturity test or attach one uniform support status to every project.

Implementation Languages and Garbage Collection Boundaries

The table is most useful when read as a structured comparison rather than as a ranked recommendation. Its "Implemented in" column identifies the host implementation language. Entries range from C, C++, Go, Rust, Haskell, Java, OCaml, and Erlang to runtimes such as the JVM and CLR. This field gives an initial compatibility signal, although it does not describe the API exposed to the host application, supported compiler versions, binary size, thread behavior, or platform matrix.

The GC column exposes another important design boundary. HAC uses stack-only management with no GC. PicoC uses manual memory management. ArkScript combines destruction with optional manual memory management, while cel-rust is listed without a garbage collector. Other entries use reference counting, tracing collection, a host runtime collector, or combinations such as reference counting plus cycle detection. These differences can determine who owns objects crossing the script boundary and whether cycles are reclaimed automatically.

The Notes column adds project-specific details that a language and GC label cannot express. Berry is described as lightweight and intended for lower-performance devices with limited memory. The CEL entries are non-Turing-complete expression languages, making them different from general scripting runtimes. DaScript is statically typed and performance-oriented. Asp runs compiled bytecode and permits blocking calls in scripts without blocking the main application. These details help define the use case, but they are brief summaries rather than complete compatibility documentation.

No score, benchmark, or single preferred implementation appears in the README excerpt. Developers must follow each project's link and evaluate its own documentation. Treating the table as neutral research material avoids turning a broad inventory into an unsupported endorsement.

Opening the Filterable Catalog and Rebuilding Its README

This repository is a documentation site, so there is no application package to install. The README directs readers to the webpage at https://dbohdan.github.io/embedded-scripting-languages/ to sort and filter the catalog interactively. That is the first useful action for most readers: compare the available fields, shortlist implementations, and then visit the linked project pages for embedding instructions.

The README is generated from a template and structured project data. Based on the repository layout and Makefile, `data/projects.toml` supplies the entries and `render-template.ts` renders them into `README.md`. The default build target is named `all`, and its prerequisite command can be invoked from the repository root as follows:

make

The Makefile defines `all: README.md`. Its rebuild rule depends on `README.md.njk`, `render-template.ts`, `Makefile`, and `data/projects.toml`. It runs `./render-template.ts README.md.njk data/projects.toml` and writes the result to `README.md`. This command requires the render script to be executable and the environment to provide whatever runtime that TypeScript script needs. The repository files do not document those runtime prerequisites or a package installation command, so there is no confirmed setup procedure for them.

The generated file is not the normal source for maintaining an entry. The repository places source data in `data/projects.toml` and the template in `README.md.njk`, so contributors should follow the repository's contribution process rather than changing only the rendered Markdown.

License Review Begins With the Selected Runtime

The catalog repository's own license is not identified in the README or repository metadata shown here. By contrast, the catalog records a license for each listed project. Those licenses include permissive options such as MIT, BSD variants, Apache-2.0, and Zlib, as well as reciprocal or other conditional terms identified as GPL, LGPL, EPL, and MPL. The README specifically emphasizes entries with strong copyleft licenses because those terms may apply beyond the interpreter source to the wider application.

That warning is relevant, but it is not a substitute for reviewing the selected project's exact license text. The catalog does not explain version-specific exceptions, linking models, distribution requirements, or how a modified interpreter affects an application. It also cannot resolve dependencies or bundled third-party components. Engineers need to inspect the license files in the chosen project and assess how the interpreter will be combined and distributed.

The catalog's mixed licensing also means there is no single license decision inherited by a user of the repository. Selecting a permissive-looking row does not automatically clear the chosen interpreter for use. Conversely, a row marked with a reciprocal license is not automatically unsuitable. It signals that a compatibility review is needed. The README uses strong-copyleft entries as warnings, so the practical value of the column is triage rather than legal determination.

Where the Catalog Falls Short as an SDK

The largest limitation is structural: this project does not prove that a listed runtime works in a particular application. The README gives no common embedding API, compatibility matrix, build recipe, security review, benchmark suite, or support policy. It also does not define how the "reasonably mature or actively developed" description is assessed. A row can help narrow research, but it cannot answer whether an interpreter supports a required callback, filesystem policy, debugger, sandbox, operating system, or compiler.

The web interface is described only as a way to sort and filter the list. The README does not document saved filters, API access, offline exports, or an automated query mechanism. The repository has no GitHub releases, so this catalog does not provide its own versioned data release through that mechanism. The source data file is present in the repository, but the README does not promise a stable schema or compatibility guarantee for external automation.

The catalog is therefore the wrong tool for deciding that two runtimes have equivalent performance, safety, or API coverage. It is also not an SDK. Anyone who needs executable embedding examples must inspect the linked implementation. Examples such as tcc's `libtcc.h` and `tests/libtcc_test.c` belong to tcc, not to embedded-scripting-languages, and the catalog does not reproduce them.

Catalog Research Versus Host-First Evaluation

A real alternative to this repository is selecting a runtime from the host ecosystem first and then consulting that project's own documentation. A C or C++ application may begin with an entry implemented in the same language, while a Go, Rust, Python, or JVM application may prefer an implementation that already shares its runtime model. This approach sacrifices the catalog's cross-language comparison, but it gives the developer direct access to current API, build, compatibility, and release information.

Another alternative is maintaining a project-specific shortlist. The relevant columns here are the implementation language, GC model, and license, but a shortlist should add hard application requirements such as native library integration, target operating systems, thread isolation, and resource limits. The catalog includes expression languages such as CEL and configuration-oriented entries such as Dhall alongside general interpreters. Those choices solve narrower problems and should not be compared as if they were drop-in replacements for unrestricted scripting.

The repository's relative strength is discovery. It puts many implementations into one filterable view and makes unusual dimensions visible, including cycle detection, stack-only management, host VM garbage collection, and non-Turing-complete execution. Its weakness is that it cannot maintain the deeper truth that belongs to each upstream project. The best use is a first-pass comparison, followed by direct evaluation of a small number of candidates.

Catalog Maintenance and Upgrading the Host Integration

The repository is not archived, and its last push was on 2026-10-04. It has no GitHub releases. Readers can identify recent repository activity, but there is no catalog-specific release stream to cite for versioned data changes. Maintenance of an individual interpreter remains the responsibility of that interpreter's own project; an update to this catalog does not establish that every linked runtime has the same maintenance status.

The build path also defines part of the maintenance cost. A contributor changing an entry may need to update `data/projects.toml`, preserve the template's expected fields, and run `make` to regenerate `README.md`. The repository files do not include a documented contributor test suite, runtime installation for `render-template.ts`, or a validation command beyond the Makefile's rendering rule. A successful build alone therefore does not confirm that a contributed entry is accurate.

For users, there is little runtime upgrade cost because this repository supplies no embedded interpreter. The potentially larger costs arise after selection: migrating application code to a different interpreter API, accounting for changes in its garbage collector or sandbox behavior, and reviewing new license or dependency terms. Those costs cannot be estimated from this catalog alone.

Editorial conclusion

Application developers can use this catalog to form a short list of candidate interpreters, but it is not evidence that any listed project fits a planned release. Engineers should first verify the selected runtime's host-language binding, memory model, license, release history, and resource limits against their own application. The final choice belongs to the linked runtime project, not to this catalog.

Frequently asked questions

Official sources

1. dbohdan/embedded-scripting-languages on GitHub
2. Issues
3. Project website
4. README