Skip to content
Introduction

FAQ

Frequently asked questions about the Tulpar programming language — what it is, how fast it is, whether it has a VM, and if it's production-ready.

3 min read

Quick answers about what Tulpar is, how it performs, and how it’s built. For anything not covered here, the Getting Started guide and Language Reference go deeper.

Tulpar is a statically-typed, AOT-compiled programming language with an LLVM backend (LLVM 18 through 22). It ships HTTP, JSON, SQLite, an ORM, and OpenAPI generation built directly into the runtime, so building an API needs no external framework or dependency install.

Tulpar compiles ahead-of-time to a native binary via LLVM. On a nine-language microbenchmark suite it beats C on fib (2.7×) and strcat (2.8×) — a lead that holds even when C is compiled with -O3 -march=native -flto — and ties C on sieve and intloop. On HTTP it serves around 36k req/s on a keep-alive benchmark using the built-in Wings server pool.

Caveats, because two earlier claims here were withdrawn after a follow-up run. On arrayiter C takes the lead back with -march=native. On strcat C wins by 1.25× once given the same hand-rolled integer-to-string routine Tulpar uses — that gap was a standard-library asymmetry, not a compiler one. The fib win also does not generalise: across the recursion family gcc still leads Tulpar on treesum, ackermann and tak. On sieve and intloop the top four languages sit within 0.5 ms, so the band is meaningful but the rank order is not. Floating point splits in two: on pure arithmetic Tulpar is indistinguishable from C (mandelbrot 158.4 vs 158.6 ms), but on float[] arrays it runs 5–27× slower — unboxed array storage exists only for integers today, so a float element costs 16.1 bytes against C’s 8.1. Hand-written SIMD, allocation-heavy and multi-threaded workloads remain untested. Full table, flag matrix and withdrawn claims in Benchmarks.

Does Tulpar have a VM, bytecode interpreter, or REPL?

Section titled “Does Tulpar have a VM, bytecode interpreter, or REPL?”

No. Tulpar dropped its bytecode VM and REPL in June 2026 in favor of a single AOT/LLVM execution path — the same model C, Rust, and Go use. Running tulpar file.tpr always AOT-compiles and runs a native binary; there is no interpreter fallback, so a successful run means the AOT pipeline genuinely ran.

Yes. Tulpar is MIT-licensed and developed in the open on GitHub.

Linux, macOS, and Windows (both MSVC and MinGW toolchains). The compiler is built with CMake and requires LLVM 18 or newer.

Terminal window
curl -fsSL https://tulparlang.dev/install.sh | bash
Terminal window
iwr -useb https://tulparlang.dev/install.ps1 | iex

Prebuilt binaries are also available from the GitHub releases page. See Installation for details.

Yes — tulpar pkg, backed by a tulpar.toml manifest and a tulpar.lock lockfile, with path, URL, and registry dependency specs. See Package Manager.

How does Tulpar compare to C, Go, or Rust?

Section titled “How does Tulpar compare to C, Go, or Rust?”

Tulpar targets Python-level ease of syntax with C-class native performance via AOT/LLVM compilation, while also including the batteries — HTTP server, JSON, SQLite, ORM, and OpenAPI generation — that C, Go, and Rust leave to third-party libraries. See Tulpar vs C for a side-by-side code comparison.