Concepts
Workflow modes
Hopskip supports workflows written in Rust, TypeScript, Python, Go and Haskell. Rust, Go and Haskell run under Wasmtime. TypeScript and Python use the V8 worker, with Python running through Pyodide.
The workflow runtime controls time, randomness and access to external operations. Workflows invoke activities for I/O; recorded activity outcomes are available during replay without executing those activities again. See determinism and activities for that boundary.
| Mode | What executes your code | Workflow languages |
|---|---|---|
| Wasm module | Wasmtime in the Wasm worker | Rust, Go, Haskell |
| V8 isolate | V8 in the V8 worker | TypeScript; Python through Pyodide |
These languages share the workflow contract, not one binary format. A Wasm memory image and a V8 heap snapshot are different artifacts. See the SDK pages for each language’s APIs and limitations.
Java and .NET
Java/JVM and .NET workflows are not supported. There is no Hopskip workflow SDK or supported build/deploy route for Java, Kotlin, Scala or C#. If your orchestration must stay in one of those runtimes, Hopskip is not currently a replacement for your workflow engine. No release date is promised.
You can keep an existing Java or .NET service behind an activity invoked by a workflow in a supported language. That is service integration, not native workflow support: the service’s process memory is not part of the workflow snapshot. Rewriting orchestration in a supported language is not a drop-in migration.
AD-VM deterministic microVM execution remains research. Neither booting an application in a VM nor running it under the local sandbox establishes supported Java/.NET workflow execution.
Wasm module
Rust, Go and Haskell compile to modules that the Wasm worker executes with Wasmtime. The host exposes the versioned workflow ABI: logical time, seeded randomness, durable sleep, activity invocation and results, searchable state and logging. It does not provide direct network, filesystem or wall-clock access to workflow code.
The guest returns to the host when suspended. Pending workflow state must be captured in linear memory and exported globals, rather than left on an active native stack.
- Rust compiles to
wasm32-unknown-unknown. - Go builds a reactor module; the build rewrites its runtime’s WASI imports into deterministic local functions.
- Haskell uses the GHC Wasm backend and a reactor module with no WASI imports.
V8 isolate
TypeScript runs as JavaScript inside the V8 worker.
The host supplies logical time and seeded randomness; workflow code uses
activities instead of fetch for external I/O.
Python runs through Pyodide, a CPython distribution compiled to WebAssembly and hosted in the V8 worker. It is not a standalone workflow module loaded by the Wasmtime worker.
Both routes expose the workflow contract through host bindings. Their capture and restore machinery belongs to the V8 host, rather than the Wasm worker’s linear-memory capture path.
AD-VM microVM
AD-VM explores deterministic execution of Linux processes in a microVM. It is not an available workflow mode for JVM, .NET, Ruby or arbitrary native binaries. Production support requires workload-specific evidence for scheduling, runtime state capture, replay, isolation and operating cost.
The local sandbox is an experimental record/replay tool. It does not control all thread interleavings or hardware clocks and is not an isolation boundary for untrusted code. A successful local recording does not qualify an application for hosted workflow execution.
HTTP integration
The webhook gateway can dispatch an activity to an existing HTTP service.
A service can return its result with a synchronous 200, or accept work
with 202 and later submit a result through the authenticated callback.
Core owns activity retry and timeout policy. External effects still need
idempotency appropriate to the activity’s contract.
This is an activity transport, not a fourth workflow runtime. The engine records the activity result; it does not snapshot the external service or enforce determinism inside it. A native service integration does not supply a Java/.NET workflow, client or worker SDK.
Which mode will my workflow use?
The build selects the runtime from the supported workflow language:
- TypeScript and Python: V8 worker.
- Rust, Go and Haskell: Wasm worker.
- Java/JVM and .NET: no supported workflow mode.
Use activities to call external systems. Neither an HTTP endpoint nor an experimental sandbox changes the supported workflow language set.