Skepa is a statically typed compiled language implemented in Rust.
Tools:
skepac: check, run, and build native artifacts
Skepa is dual-licensed under either the MIT License or the Apache License, Version 2.0, at your option.
Download from GitHub Releases:
- Windows:
skepa-windows-x64.zip - Linux:
skepa-linux-x64.tar.gz - macOS Apple Silicon:
skepa-macos-arm64.tar.gz
Extract the archive and keep skepac together with the shipped runtime library (libskepart.a on Unix, plus skepart.dll / import libs on Windows). Add that directory to PATH.
build-native finds the runtime beside the skepac executable. To point at a different location, set SKEPA_RUNTIME_DIR to a directory that contains the runtime library.
cargo install --git https://github.com/AayushMainali-Github/skepa-lang skepaccargo install only installs the skepac binary. For build-native, also place libskepart.a (and on Windows the skepart DLL / import libs) beside skepac, or set SKEPA_RUNTIME_DIR. Prefer the prebuilt archives or the local install scripts below when you need native builds.
Windows (PowerShell):
./scripts/install.ps1Linux/macOS (bash):
./scripts/install.shThese scripts install skepac and copy the native runtime library next to it.
Manual:
cargo install --path skepac
cargo build --release -p skepart
# then copy target/release/libskepart.a (and Windows DLL artifacts) beside ~/.cargo/bin/skepacskepac check app.sk
skepac run app.sk
skepac build-native app.sk app.exe
skepac build-obj app.sk app.obj
skepac build-llvm-ir app.sk app.llbuild-obj and build-native keep local cache metadata, compiled object artifacts, and reusable linked native outputs under .skepac-cache/, so unchanged builds can skip recompilation, relink from a cached object, or restore a missing executable from the cached linked artifact.
On Windows GNU builds, build-native emits the executable plus skepart.dll beside it. Keep both files together when you move or run the built artifact.
If build-native reports that the native runtime library is missing, ensure libskepart is next to skepac or set SKEPA_RUNTIME_DIR.
Set SKEPAC_TIMINGS=1 to print per-phase timing lines for build-obj and build-native when you want to inspect cache hits, codegen cost, and link cost locally.
Set SKEPA_CODEGEN_TIMINGS=1 to print lower-level backend stage timings from skeplib itself, including LLVM IR emit, llvm-as, clang object codegen, and native link phases.
Compiler-internal Criterion benchmarks live in skeplib/benches/full_stack.rs:
cargo bench -p skeplib --bench full_stackCross-language comparison benchmarks live in benchmarks/comparison/ and generate detailed CSV, JSON, and Markdown reports:
.\benchmarks\comparison\run.ps1Skepa projects are file-system based. The CLI takes an explicit entry file, usually main.sk.
Recommended small-project layout:
my_app/
main.sk
lib.sk
utils/
math.sk
Example:
// utils/math.sk
fn add(a: Int, b: Int) -> Int { return a + b; }
export { add };
// main.sk
from utils.math import add;
fn main() -> Int {
return add(20, 22);
}
Run it with:
skepac check main.sk
skepac run main.skShipped sample apps live under examples/.
examples/hello/main.sk- minimal single-file program
examples/inventory/main.sk- multi-file project with structs,
Vec, imports, and user-facing output
- multi-file project with structs,
examples/nested_loops/main.sk- CPU-heavy nested-loop sample with 10k x 10k iteration space and cross-loop integer mixing
Try them with:
skepac check examples/hello/main.sk
skepac run examples/inventory/main.sk
skepac check examples/nested_loops/main.skFolder namespaces map directly to import paths:
utils/math.sk->utils.mathstring/case.sk->string.casea/mod.sk->a.mod
There is no skepac test command yet.
Current recommended workflow for user programs:
- keep small executable checks in
.skfiles with amain() -> Int - return
0for success and non-zero for failure - run them with
skepac run <entry.sk> - use
skepac check <entry.sk>in fast validation loops before native runs
For multi-file projects, point skepac at the entry file for the specific executable check you want to run.
For full language/module reference, see DOCS.md.
For the internal runtime and FFI ABI contract, see RUNTIME.md.
For language specification authority and compatibility rules, see LANGUAGE_POLICY.md.
For current support targets, release expectations, and production-hardening status, see PRODUCTION.md.
See .github/CONTRIBUTING.md for contribution workflow and commit message guidance.
See TESTING.md for testing expectations and validation commands.