Spokes.wiki Search About
Defined Term architecture updated Thu Aug 06 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

Hosted language

A language designed to run on a runtime it did not create, taking that host’s type system, garbage collector, threads and library ecosystem instead of building its own. clojure states the choice outright — it targets the JVM, the CLR and JavaScript, and interoperating with the host is a language feature, not a foreign-function afterthought. elixir is the same move against BEAM, the Erlang virtual machine, and inherits that VM’s processes, per-process collection and supervision trees.

The trade is explicit. A hosted language gets a mature runtime and an existing library corpus on day one, and it can never be smaller or faster than its host, nor deploy where the host cannot go. rust and c are the opposite pole: they own their execution model and can run with no runtime at all.

The strongest case: the same language on two hosts (added 2026-08-05)

clojure targets the JVM, the CLR and JavaScript. jank takes Clojure’s syntax and semantics and re-hosts them on C++, swapping Java interop for C++ interop and adding an LLVM JIT for the REPL with AOT for shipped binaries. Two implementations of one language on unrelated runtimes is the closest thing to a controlled experiment this spoke can hope for: what stays is the language, what changes — startup, interop surface, deployment space, memory behaviour — is the host.

dart and kotlin add the multi-host variant, targeting native, JS and Wasm (Dart) and the JVM, JS, native and Wasm (Kotlin) from one source. So “hosted” is not a binary. A language can pick a host, pick several, or be moved to a new one by somebody else.

Node.js is the case that clarifies the term

nodejs is in this corpus but is not a language — it is a runtime that hosts one. That inversion is useful. JavaScript’s concurrency story in the browser and its concurrency story on a server are different because the host differs, not because the language does. So a claim about “what JavaScript is like” is usually a claim about V8 plus a host, in the same way that a claim about Clojure’s threading is a claim about the JVM.

Which suggests the distinction worth keeping: a language defines what programs mean; a runtime decides what they can do. Most of what the founding corpus’s home pages advertise — pause times, parallelism, deployment shape, startup cost — belongs to the second.

Hosted on a language, not a runtime (added 2026-08-06)

typescript moves the term again. Its host is not a VM but JavaScript itself: it compiles by deleting its own annotations, and the artefact that runs is a program in the language it extends. So it inherits its memory model, concurrency model and deployment space not from a chosen runtime but from whatever host runs the output — a browser, nodejs, Deno, Bun. kotlin and dart also emit JavaScript, but they compile across a gap; TypeScript’s host and source are the same language, which is why a TypeScript file with the types stripped is still a valid program.

Both ends of one pair, and a host with no page (added 2026-08-06)

erlang joined the corpus, so BEAM is now described by its own language as well as by its guest. elixir sells supervision, per-process collection and distribution; Erlang’s page sells the same properties as the runtime’s. Nothing conflicts, and that agreement is the finding — the guest’s most distinctive claims are inherited, and both pages say so.

The JVM is the opposite case. clojure, kotlin and jank all define themselves against it and java‘s public page says nothing about it, so the corpus’s most-depended-on host is its least documented. scheme adds Kawa on the JVM: the same re-hosting move as Clojure’s, made earlier and without the immutability commitments.

programming-language · clojure · elixir · erlang · java · scheme · nodejs · typescript · type-system · concurrency-model · memory-management-model · synthesis