Native
--target=native
Executables for your host platform, with native networking, files, processes, and a choice of memory backends.
Build a native app →A practical language with strong inferred types, explicit errors, first-class effects and lightweight concurrency. Compile through LLVM to native programs, WebAssembly, or shared app logic for iOS and Android.
Strong types and explicit failure, without noisy annotations.
type Lookup = Found { value: int } | Missing
fn doubleFound(result) = match result {
Found { value } => Success(value * 2)
Missing => Error("value not found")
}
match doubleFound(Found { value: 21 }) {
Success(value) => print("result: ${value}")
Error(message) => print("error: ${message}")
}
Running on iOS and Android
Issue Inbox puts the model, reactive updates, UI layout, GitHub decoding, and SQLite commands in shared Osprey modules. SwiftUI and Android widgets render the same application.
Actual simulator and emulator captures. The iOS app has also been installed and verified on a physical iPhone. Native hosts supply rendering, SQLite, HTTPS, and lifecycle services through the generated C interface.
Build a native executable, a WebAssembly module, or application logic for a native mobile host.
--target=native
Executables for your host platform, with native networking, files, processes, and a choice of memory backends.
Build a native app →--target=wasm32
A WASI module with browser examples that connect Osprey application logic to a JavaScript host.
Build a web app →--target=ios / ios-sim
ARM64 app-logic archives and C headers for iPhone and simulator applications, called from Swift.
Build for iOS →--target=android-arm64 / android-x64
ARM64 and x86-64 app-logic archives and C headers, linked into Android applications through JNI.
Build for Android →The compiler rejects unsupported operations before generating code, including resumable effects on mobile and WebAssembly. See target capabilities and current limits.
Osprey combines functional clarity with systems-oriented deployment. The features fit together around four priorities: practical code, safety, performance and elegance.
Write direct code, call existing C libraries, and build native, WebAssembly, iOS, or Android applications. Useful abstractions should remove work, not create ceremony.
Expected failures use results, pattern matching checks every case, arithmetic does not silently wrap and fibers avoid shared mutable state.
LLVM compilation, lightweight fibers, persistent collections and selectable memory management give high-level code a systems-oriented runtime.
Type inference, immutable data, direct-style concurrency and first-class effects keep the important parts visible and the plumbing out of the way.
Osprey uses inferred static types, explicit result values and exhaustive pattern matching. You get strong checks without repeating obvious type information throughout the program.
type Payment = Approved { receipt: string }
| Declined { reason: string }
fn describe(payment) = match payment {
Approved { receipt } => "paid: ${receipt}"
Declined { reason } => "declined: ${reason}"
}
effect Logger {
log: fn(string) -> Unit
}
fn process(orderId) !Logger = {
perform Logger.log("processing ${orderId}")
orderId * 2
}
handle Logger
log message => print(message)
in process(21)
Code can log, store data or retry work without passing service objects through every intermediate function. Swap a handler in a test without changing the code under test.
Effect inputs and outputs are type-checked. If an operation has no matching handler, the compiler rejects the program and names the missing effect. Target checks also reject unsupported effect resumption.
Spawn concurrent work without turning every function in the call chain into a special async kind. Fibers communicate by moving or copying values through channels rather than sharing mutable state.
fn work(n) = n * n
let first = spawn work(6)
let second = spawn work(7)
print("${await(first)}, ${await(second)}")
let messages = Channel(1)
send(messages, "done")
print(recv(messages))
Osprey compiles through LLVM with no VM or JIT warm-up. Choose the memory strategy that fits the build, and use the same language semantics across those choices.
Compile executables, WebAssembly modules, or C ABI libraries for native iOS and Android hosts.
Native builds can use the default non-reclaiming allocator, tracing garbage collection or Perceus reference counting.
Immutable lists and maps reuse unchanged structure, so an update does not copy the entire collection.
Declare and link the C functions you need. C code remains outside Osprey's memory-safety guarantee.
Performance claims belong with measurements. See the reproducible cross-language benchmarks →
Choose familiar braces and calls or clean ML-style layout and currying. Both flavors use the same type system, effects, runtime and backends; neither is a reduced or secondary form of Osprey.
.ospBraces, fn and familiar function calls for developers coming from C#, Go, Rust, Java, Kotlin or Swift.
fn greet(name) = {
let message = "Hello, ${name}"
print(message)
}
greet("Ada")
.ospmlLayout-sensitive syntax, currying and whitespace application for developers at home in ML, OCaml, F# or Haskell.
greet name =
message = "Hello, ${name}"
print message
greet "Ada"
Files choose a flavor independently. Issue Inbox combines ML application modules with a small Default-flavor C entry point in one project. Read about the two flavors →
Use the browser playground, or install the compiler and build a native program.
brew install nimblesite/tap/osprey
scoop bucket add nimblesite https://github.com/Nimblesite/scoop-bucket
scoop install osprey
Start in the playground, follow the documentation or explore the compiler on GitHub.