Feature Status

By Christian Findlay

Osprey is an alpha language. The compiler is written in Rust, emits LLVM IR and builds native executables, wasm32-wasip1 modules, and app-logic libraries for iOS and Android. Each target has an explicit runtime boundary.

Current version: v0.16.0.

Releases

Version Released
v0.16.0 Aug 14, 2026 Latest
v0.15.0 Jul 28, 2026
v0.14.0 Jul 25, 2026
v0.13.0 Jul 24, 2026
v0.12.0 Jul 22, 2026
v0.11.0 Jul 12, 2026
v0.10.0 Jul 1, 2026
v0.9.0 Jun 29, 2026
v0.8.0 Jun 29, 2026
v0.7.0 Jun 28, 2026
v0.6.0 Jun 27, 2026
v0.5.0 Jun 25, 2026
v0.4.0 Jun 23, 2026
v0.3.0 Jun 23, 2026
v0.2.1 Jun 20, 2026
v0.2.0 Jun 23, 2025
v0.1.0 Jun 13, 2025

Implemented foundations

  • Default (.osp) and ML (.ospml) source parsing, both lowering to the same AST before semantic analysis
  • Hindley–Milner type inference, algebraic data types and exhaustive pattern matching for supported patterns
  • Typed effect operations, lexical handlers, compile-time rejection of missing handlers, and single-shot resume for --target=native
  • Immutable persistent lists and maps
  • Lightweight native fibers and channels
  • Native HTTP, WebSocket, file, process and C FFI runtime APIs
  • Default, tracing-GC and Perceus-ARC native memory backends
  • Native and wasm32-wasip1 compilation, plus iOS and Android C ABI targets
  • A shared modular mobile application with reactive native UI, SQLite cache, live GitHub requests, and local notes and priorities
  • Compiler-backed formatting, documentation generation, testing, profiling and language-server commands

The runnable programs in tests/regressions/ are compiled and compared with checked-in expected output.

Target support

Target Output Runtime boundary
native Executable for the host platform Native runtime, including resumable effects; default, GC, or ARC memory
wasm32 WebAssembly module WASI/browser host; default memory; unsupported features rejected before code generation
ios, ios-sim ARM64 static archive and C header Swift host, iOS 15 minimum; default memory; no resumable effects
android-arm64, android-x64 ARM64 or x86-64 static archive and C header Android host and JNI, API 26 minimum; default memory; no resumable effects

The compiler rejects unsupported target operations during --check, --llvm, and compilation. iOS and Android reject resume and unavailable built-in process, HTTP, and WebSocket operations. Their hosts provide platform networking through the C boundary. WebAssembly also rejects fibers, terminal control, and arbitrary C imports; approved browser imports and supported host filesystem operations remain available.

Issue Inbox demonstrates the same Osprey project on iOS and Android, including ML modules and a small Default-flavor C entry point. Its screenshots come from actual simulator/emulator runs. The iOS app has also been installed and verified on a physical iPhone. Both Android ABIs execute the shared test corpus through the C ABI.

Current limits

  • Resumable effects are supported by --target=native. Mobile C ABI targets and WebAssembly reject them at compile time; supported handlers that return immediately remain usable.
  • The effect checker follows operations through the closed program, including exported mobile functions. It does not yet provide general polymorphic effect-row variables in public higher-order signatures.
  • Tail-call optimisation is not implemented.
  • User-defined generics and the package manager remain roadmap work. Working project/module examples do not imply every module-system feature is complete.
  • The strict static-memory mode described in the memory specification is not a current CLI option. Native builds accept default, gc, and arc; mobile and WebAssembly accept default only.
  • The initial mobile runtime retains general allocations for process lifetime and has no public library teardown or returned-string release API.
  • The mobile sample reads one public GitHub issue page. Authentication, pagination, background refresh, and posting changes to GitHub are not implemented.
  • C integrations are outside Osprey's memory-safety guarantee.

For detailed intended behavior and chapter-specific implementation notes, read the specifications. For compiler-generated built-in signatures, use the API reference.