TulparLang

Python-easy syntax. C-class performance. HTTP-ready out of the box.

---

What is TulparLang?

TulparLang is an open-source, ahead-of-time compiled programming language built on LLVM (18 through 22), with static type checking: annotated code is checked at compile time and lowered to native types, while unannotated parameters and json values stay dynamically typed (boxed) at run time. It pairs Python-shaped syntax with native binary performance. On a nine-language microbenchmark suite where every language reads its workload size from the environment and the outputs are verified to match, Tulpar AOT beats C on fib (by a margin that grows with n — a point on a curve, not a constant: 2.7× vs gcc -O3 -march=native -flto in the flag-matrix run, 4× vs gcc -O2 at n=32 in benchmarks/fair/RESULTS.md) and ties it on sieve and intloop**, while C takes arrayiter and strcat once given equal flags and the same integer-formatting routine. See Performance for the flag matrix and the follow-up attribution run. On a localhost JSON-API micro-benchmark (2026-05, 4 connections) the listen_async Wings listener served ~1.9× the throughput of Node.js' built-in http; a 2026-09-28 re-measurement with a native load generator and 50 connections puts a single-threaded Wings at 1.3× single-process Node and a Wings worker pool at 0.8× Node cluster (details under Performance). It ships with a batteries-included standard library so you can build a production HTTP/HTTPS API without installing a single external dependency.

Files use the .tpr extension. The whole toolchain — compiler, runtime, package manager, formatter, language server, and REST framework — is a single ~7 MB executable. Source code, identifiers, and strings are UTF-8 throughout, with first-class support for both Turkish and English keywords and diagnostics.

Use it for: dependency-free native backend services, REST APIs and microservices, CLI tools, scripting and automation. The sweet spot is "Python-shaped ergonomics with a single-binary deploy and no runtime to install on the target machine" — if that matches your shape, the rest of the README is for you.

Highlights:

• Native HTTP/HTTPS server — four listener flavours (sync, thread- per-connection, worker pool, single-thread event loop) plus a TLS listener with OpenSSL, all in the bundled wings / wings_tls stdlib.
• First-class JSON — built-in type, literal syntax, dot access, toJson / fromJson round-trips, no library import required.
• AOT-compiled native binaries — tulpar build foo.tpr produces a standalone executable you can ship without the Tulpar toolchain.
• One-line installer with auto-update — iwr ... | iex on Windows, curl ... | bash on Linux/macOS, then tulpar update to roll forward.

---

Install

Windows (PowerShell):

iwr -useb https://tulparlang.dev/install.ps1 | iex

Linux / macOS:

curl -fsSL https://tulparlang.dev/install.sh | bash

Both scripts download the latest release, drop tulpar into a per-user location (%LOCALAPPDATA%\Programs\Tulpar on Windows, ~/.local/bin on Linux/macOS), and wire up PATH. No admin rights needed. Run tulpar update later to upgrade in place.

Prefer a GUI? Download tulpar-setup-windows-x64.exe from the latest release — per-user install, no admin prompt, PATH wired up, Start Menu and Add/Remove Programs entries. Or take tulpar-windows-x64.zip for a portable folder: unzip anywhere, run tulpar.exe from inside it, nothing is written outside. Both are self-contained — CI checks on every build that the binary imports nothing beyond Windows system DLLs and the MinGW ones shipped alongside it. One caveat on Windows: compiling a program (tulpar file.tpr, tulpar build) links through clang++, which the packages do not ship — install it from an MSYS2 MINGW64 shell (pacman -S mingw-w64-x86_64-clang) and put mingw64\bin on PATH. tulpar version, fmt, typecheck, pkg and --lsp work without it.

Verifying releases

Every release ships with SHA256SUMS.txt (asset hashes) and SHA256SUMS.txt.asc (a detached GPG signature over that manifest by the TulparLang Release key). The install scripts already verify the SHA-256 hashes; the GPG signature is an optional extra layer.

# Import the release-signing public key (one-time)
curl -fsSL https://raw.githubusercontent.com/hamer1818/TulparLang/main/release-public.asc \
  | gpg --import

# Verify (download both files from the release page first)
gpg --verify SHA256SUMS.txt.asc SHA256SUMS.txt
sha256sum -c SHA256SUMS.txt

Public key fingerprint:

CE5C 22BD EA61 58BC 8221 3A7E  4396 41B3 0E8D FDEE

The key is ed25519, valid until 2028-05-09, used only for release signing. If gpg --verify reports Good signature and the fingerprint matches, the manifest came from the release workflow unchanged.

Quick start

Create hello.tpr:

str message = "Merhaba, dünya!";
print(message);

func square(int n): int {
    return n * n;
}

print(square(5));   // 25

Run it:

tulpar hello.tpr

The default tulpar <file> invocation AOT-compiles via LLVM and runs the resulting native binary — Python-shaped syntax, native-binary performance (see Performance for the actual numbers).

Build a REST API in 8 lines

import "wings";

func home(req) {
    return {"hello": "world", "ts": now_iso8601()};
}

get("/", home);
serve(8080);

tulpar build api.tpr && ./api
curl http://127.0.0.1:8080/
# {"hello":"world","ts":"2026-05-07T18:30:00Z"}

A persistent CRUD API in 7 lines

model() creates the SQLite table, resource() wires five REST routes plus request validation (422) and Swagger /docs — all queries run as bound-parameter SQL:

import "wings";
import "orm";

database("notes.db");
json Note = model("notes", {"id": "pk", "title": "str!", "done": "bool"});

resource("/notes", Note);   // GET/POST /notes, GET/PUT/DELETE /notes/:id
serve();                    // :8484 + /docs

Custom endpoints live right next to it, with ActiveRecord-style calls: Note.find(3), Note.where("done = ?", [0]), Note.create({...}), Note.save(obj). See examples/wings_orm_resource.tpr and the full cheatsheet in WINGS_CHEATSHEET.md.

Need HTTPS? Swap serve(8080) for wings_tls(8443, "server.crt", "server.key") and you're terminating TLS via OpenSSL with the same handler API. Wings auto-registers /healthz + /metrics and answers CORS preflights so a browser can hit the API immediately.

Streaming (SSE / WebSocket)

Long-lived connections take over the socket and signal {"_stream": 1} so wings skips its normal response envelope:

import "wings";

func events() {
    int fd = wings_current_fd();
    socket_send(fd, wings_sse_headers());
    int i = 0;
    while (i < 5) {
        socket_send(fd, wings_sse_event("tick", "{\"n\":" + toString(i) + "}"));
        sleep(300);
        i = i + 1;
    }
    return {"_stream": 1};
}

get("/events", "events");
listen(8093);

curl -N http://127.0.0.1:8093/events will print 5 tick frames live. WebSocket handlers use wings_ws_upgrade(req) for the handshake, wings_ws_send_text(fd, payload) + wings_ws_recv_frame(fd) for the frame loop, and the same {"_stream": 1} return value.

Package management

Vendored stdlib (wings, router, http_client, orm, …) is embedded in the binary — no install step. Third-party packages flow through tulpar pkg:

tulpar pkg init my-app           # writes tulpar.toml + default registry URL
tulpar pkg search                # browse the catalog (empty query = all)
tulpar pkg search wings          # filter by name + description
tulpar pkg info demo             # version list, downloads, install hint
tulpar pkg add demo@^1.0         # add a dependency line
tulpar pkg install               # vendor everything into tulpar_modules/
tulpar pkg publish --token $T    # publish current package to the registry

tulpar pkg init seeds the canonical registry (https://api.pkg.tulparlang.dev); override via the [registry] url line in tulpar.toml, --registry <url> flag, or TULPAR_REGISTRY env. Semver ranges are full 2.0.0 (^, ~, *, >=,<, pre-release plus build metadata). Installs go through a lockfile (tulpar.lock) with SHA-256 checksums so re-installs are byte-stable.

Why TulparLang

• Native speed. LLVM AOT compilation, in C's performance class on integer kernels and scalar floating point: ahead of C on fib (the margin grows with n), tied on sieve, intloop and mandelbrot, and far ahead of Node/Python/Java/C# there. Float-array code is the exception — still boxed, 11–27× C (nbody, matmul). On a localhost JSON-API microbenchmark (2026-05) the listen_async Wings listener was 1.91× Node.js' http and 2.91× CPython's ThreadingHTTPServer; the 2026-09-28 re-measurement below is more modest. See Performance and benchmarks/fair/README.md for the methodology.
• No build step for prototyping. tulpar file.tpr runs in one step. tulpar build file.tpr produces a standalone native binary when you want to ship.
• Batteries included. Wings (HTTP server, four listener flavours + TLS), TulparAPI (FastAPI-style routing), ORM (SQLite), HTTP client, sockets, threads, regex, CSV, datetime, structured logging, OpenAPI generation — all in the default install. No package manager required for the standard library.
• First-class JSON. json is a built-in type with literal syntax ({"k": v}), dot access (obj.key), and toJson / fromJson round-trips that survive Unicode, embedded quotes, deeply nested structures, and large arrays.
• HTTPS out of the box. Statically linked OpenSSL on every platform. Both client (http_get("https://...")) and server (wings_tls(...)) work with no extra setup.
• UTF-8 native. Source code, strings, identifiers, error messages all UTF-8. Localised CLI follows the system locale; override with TULPAR_LANG=tr or TULPAR_LANG=en.
• Single-binary toolchain. One tulpar executable bundles the AOT/LLVM compiler, package manager, formatter, language server, and self-updater.
• Editor-aware. A real LSP server (tulpar --lsp) drives the bundled VS Code extension with Rust-style diagnostics, hover types, completion, go-to-definition, find-references, rename, and signature help.

Performance

Cross-language microbenchmarks

Wall time, best of 7 runs, in milliseconds. Lower is faster; the fastest entry in each column is bold. Run python3 benchmarks/fair/run.py to reproduce; last run on commit 3edb4f4 (Linux, LLVM 22).

Language	fib(32)	sieve(5M)	strcat(2M)	arrayiter(5M)	intloop(50M)
Tulpar AOT	0.6	7.7	13.2	1.2	134.5
C (gcc -O2)	1.6	7.6	37.6	2.2	134.4
C++ (g++ -O2)	1.9	8.0	14.7	2.7	134.9
Rust (-O3)	3.8	8.1	18.7	1.5	144.0
Go	6.7	8.5	24.3	4.3	134.5
Java	12.4	19.7	32.9	18.2	144.1
C# (.NET)	20.3	20.9	31.2	18.3	149.3
Node.js	24.6	28.2	96.4	18.5	712.2
Python	140.8	448.1	200.0	410.2	3127.3

Empty-program baseline on the same machine (process start-up, included in every number above): C 0.17 · Tulpar 0.23 · C++ 0.44 · Python 5.6 · C# 8.2 · Node 10.7 ms.

Tulpar AOT is the fastest of the nine on fib, strcat and arrayiter, and within 0.1 ms of C on sieve and intloop.

Does the lead survive C's best compiler flags?

The table above compiles C with gcc -O2, the same generic baseline Tulpar itself targets (its LLVM target CPU is "generic" by default; -march=native is opt-in and not used for these numbers). That is a fair default, but "faster than C" is an extraordinary claim, so the comparison was re-run with C given its best flags — 12 interleaved repetitions, median ± MAD, on one AMD Ryzen 7 9800X3D (Zen 5, 5.27 GHz):

Benchmark	C -O2	C -O3 -march=native -flto	Tulpar (generic)	Verdict
fib(32)	2.49	2.08 ± 0.04	0.77 ± 0.02	Tulpar 2.7× — holds
strcat(2M)	37.95	36.98 ± 0.37	13.27 ± 0.21	Tulpar 2.8× — holds
sieve(5M)	7.86	7.75 ± 0.14	7.77 ± 0.10	tie (inside MAD)
arrayiter(5M)	2.50	1.85	2.03	C wins with native

So the honest statement is narrower than a single "beats C": fib is a robust win that survives C's best flags, sieve and intloop are ties, and arrayiter is a Tulpar win only at equal generic flags — C takes it back with -march=native.

strcat was withdrawn as a win. A follow-up control gave C the same hand-rolled integer-to-string routine Tulpar uses instead of snprintf: C then runs it in 11.07 ± 0.10 ms against Tulpar's 13.85 ± 0.39 — C is 1.25× ahead. The original 2.8× "win" was entirely the snprintf-versus-specialised-itoa asymmetry, i.e. a standard-library comparison, not a compiler one.

And the fib win does not generalise. Running the whole self-recursion family — ackermann, tak, treesum, plus a mutual recursion negative control — showed the clone-chain pass gaining 6.33× on fib but only 1.04–1.57× elsewhere, and regressing ackermann by 21%. Diagnosing that regression found the chain depth was simply too large: a single clone is enough to break the self-recursion SCC edge, and deeper chains only add code and layout churn. SELFREC_DEPTH went 4 → 1, which removed the regression and made fib faster still (0.67 → 0.47 ms).

Even so, gcc still beats Tulpar across the rest of that family — treesum 3.6×, ackermann 3.2×, tak 1.5× — while Tulpar leads clang and rustc there. "Faster than C at recursion" is not supported; only fib is. Full diagnosis, depth sweep, matched clang/rustc baselines and raw CSV: benchmarks/fair/recursion/.

Useful calibration from that run: compiling the same C source with gcc versus clang swings the result by 1.21×–3.82× on these kernels. Any cross-language gap smaller than that is a compiler difference, not a language one.

Two further disclosures the numbers alone don't carry:

• strcat compares different tools, not just different compilers. C's version is a proper geometric-growth buffer (not a naive realloc-per-iteration loop), but it formats each number with snprintf, a general-purpose formatter, while Tulpar uses a specialised integer-to-string routine that was optimised for exactly this path. A C programmer hand-rolling itoa would close much of that gap.
• fib measures inlining, not just call overhead, despite its label. Both languages genuinely execute the exponential tree — timing scales as φ² per +2 in n (measured: C 2.67×, Tulpar 2.30×), so neither is collapsing it to a linear form. But Tulpar's lower exponent shows part of its lead comes from the self-recursion clone chain enabling subexpression sharing the C build does not get — and that pass, measured across the recursion family, turns out to be a fib outlier rather than a general win.

What this suite does not establish

Five integer/string kernels on one machine cannot support "fastest language". Floating point is now measured in the same harness (benchmarks/fair/RESULTS.md) and splits in two: scalar FP is C-class (mandelbrot 158.4 vs C 158.6 ms, ≈1.00×), float arrays are not (nbody 11.6× C, matmul 26.6× C) because float[] elements are still boxed. Not covered: SIMD, allocation pressure and hash-map/JSON workloads — which is where the arena model's costs would actually appear — pointer chasing, sorting, multi-threaded scaling, RSS, and sustained-load p99 latency. The defensible reading is: Tulpar is in C's performance class on integer kernels and scalar FP, an order of magnitude behind on float arrays, and decisively ahead of Node/Python/Java/C# on the integer side. Its flat loop and recursion codegen is C-class, not above it; the one verified win over C is fib.

How these numbers are kept honest

An earlier version of this table (still visible, clearly marked, in benchmarks/RESULTS.md) was audited in September 2026 and thrown out. It had three flaws that each invalidated the result on their own — the worst being that only Tulpar read its workload size at run time, while gcc -O2 and rustc -O3 folded their loops to a closed form and "won" without executing them. The suite in benchmarks/fair/ fixes all three:

• Every language reads BENCH_N from the environment, so no compiler can constant-fold the workload away.
• Same algorithm, same data structure, with each language using its own idiomatic tool (StringBuilder / std::string / strings.Builder / Int32Array / int[]) — forcing a naive form on someone measures the trap, not the language.
• Outputs are compared across languages; if they disagree the row is reported invalid instead of published.
• Warm-up run discarded, best and median reported, and the empty-program baseline printed alongside so you can see how much of a number is process start-up.

Scope. These are microbenchmarks — tight loops on a single machine. They isolate compiler and runtime costs and let Tulpar be compared against C, Rust, Go and Node on the same shape of workload. They do not model production traffic (cold starts, large payloads, distributed clients, p99 tail latency, GC pressure under load).

HTTP throughput

* These figures come from listen_pool, a multi-threaded listener, and Wings keeps mutable globals (request counters, the router table). Tulpar has no memory model: shared mutable state across threads is neither atomic nor reliably visible — measured, with reproducers, in docs/mindmap/Concurrency.md. The throughput number itself is real; the concurrency contract underneath it is undocumented and untested, so treat the counters as approximate until that gate closes.

Baked from local benchmark run (best of 5). Last run: 2026-05-21T08:23:24Z UTC · commit d91f184 · runner Windows · developer machine (16 CPUs). Methodology + Local Run instructions: benchmarks/CI.md.

⚠ These tables are from 2026-05-21 (Windows dev machine, Python client, 4/16 connections, single run — the pre-audit harness in benchmarks/CI.md). A 2026-09-28 re-measurement on Linux (Ryzen 7 9800X3D, native benchmarks/loadtest.c, 50 keep-alive connections, turn-paired, node v26.10.0) could not reproduce the 1.6–2.8× lead: listen_evented vs single-process Node 1.29–1.32× (275k / 208k RPS), listen_pool vs Node cluster 0.81–0.83× (1.01M / 1.23M RPS — Node ahead across cores). See benchmarks/WINGS_STRESS.md.

3000 GETs across 4 keep-alive connections, single localhost loop. Same JSON handler running on every server.

Low concurrency

3 000 GETs over 4 keep-alive connections; single localhost run; each server hosting the same JSON handler. Apples-to-apples view: one client thread per connection. Higher req/sec is better.

Server	Scheduling model	req/sec	vs Node.js
Tulpar listen_pool	worker pool sized to host CPU count, sharing accept()	64 085	2.77× faster
Tulpar evented + cache	evented + wire-byte cache for cached_get routes	62 057	2.68× faster
Tulpar listen_evented	single thread, poll()-multiplexed	60 316	2.61× faster
Tulpar listen_async	OS thread spawned per connection	50 244	2.17× faster
Tulpar listen	single thread, one request at a time	29 458	1.27× faster
Node.js http	single-thread event loop	23 133	(baseline)
Python ThreadingHTTP	OS thread spawned per request	14 755	1.57× slower

5 of the Tulpar Wings listeners at this concurrency beat Node.js' built-in http, by 1.27×–2.77× depending on scheduling model.

High concurrency

12 000 GETs over 16 keep-alive connections; single localhost run; each server hosting the same JSON handler. Same per-thread workload as the low-concurrency block, scaled up to surface multi-core scaling. Higher req/sec is better.

Server	Scheduling model	req/sec	vs Node.js
Tulpar listen_evented	single thread, poll()-multiplexed	56 303	1.65× faster
Tulpar evented + cache	evented + wire-byte cache for cached_get routes	55 843	1.64× faster
Tulpar listen_pool	worker pool sized to host CPU count, sharing accept()	55 143	1.62× faster
Tulpar listen_async	OS thread spawned per connection	54 385	1.59× faster
Node.js http	single-thread event loop	34 138	(baseline)
Tulpar listen	single thread, one request at a time	28 422	1.20× slower
Python ThreadingHTTP	OS thread spawned per request	14 611	2.34× slower

4 of the Tulpar Wings listeners under this load beat Node.js' built-in http, by 1.59×–1.65× depending on scheduling model.

Reproduce locally: see benchmarks/CI.md for how to run the full CPU and HTTP benchmark suite.

Wings — four ways to listen

Wings is the embedded HTTP framework. The front door is serve(): serve() picks the branded default port 8484, serve(8080) binds an explicit port, and serve(8080, 4) runs a 4-worker thread pool. The listeners below are the advanced modes behind it; the handler API stays the same, only the scheduling model changes:

Listener	Best for
listen(port)	Sync. One in-flight request. Simplest.
listen_async(port)	Thread per connection. Best for short bursts.
listen_pool(port, n)	Pre-spawned workers. Best sustained RPS.
listen_evented(port)	Single-thread + poll() / WSAPoll. Best for many idle keep-alive conns (chat, dashboards, SSE).
wings_tls(port, cert, key)	HTTPS via OpenSSL. Same handler API.

All five share _request, _response, route counters, /healthz / /metrics auto-routes, OPTIONS preflight handling, structured logging, and OpenAPI 3.0 generation via wings_openapi(title, version).

Long-lived connection types (Server-Sent Events, WebSocket upgrade) take over the socket and return {"_stream": 1} so the dispatcher skips its envelope build — see Streaming above and examples/api_wings_sse.tpr / examples/32_wings_ws_frames.tpr for end-to-end demos.

Command reference

The full list lives at https://tulparlang.dev/reference/cli/; the short version:

tulpar <file.tpr>             # Run via AOT (the only execution path; native speed)
tulpar build <file.tpr> [out] # Standalone native binary

tulpar fmt <file.tpr>         # Source formatter
tulpar typecheck <file.tpr>   # Standalone typechecker
tulpar pkg <subcommand>       # Package manager:
                              #   init, list, add, remove, install,
                              #   search, info, publish
tulpar doc <file.tpr>         # Markdown reference generator
tulpar debug <file.tpr>       # DAP server (VS Code debugger)
tulpar --lsp                  # Language server (editor integration)

tulpar cache [info|clean|dir] # Compile cache (see below)

tulpar version                # Show installed version
tulpar update [--check]       # Self-update from tulparlang.dev
tulpar --help                 # Show command reference

Compile cache. Running or building the same program again with identical inputs skips compilation: tulpar app.tpr runs the cached binary directly (a 28-line wings program 576 → 6.9 ms, hello world 48 → 4.4 ms; Ryzen 7 9800X3D, Linux, 2026-10-05). The key is content-addressed — the source and every transitively imported module's content, tulpar.toml, extension manifests/modules/archives, the runtime archive, the link driver, the compiler binary itself and every TULPAR_* variable the compiler could read — so touch alone never misses and a changed input never hits. Binaries live in ~/.cache/tulpar ($XDG_CACHE_HOME; macOS ~/Library/Caches/tulpar; Windows %LOCALAPPDATA%\tulpar\cache; TULPAR_CACHE_DIR overrides), capped at 512 MB with LRU eviction (TULPAR_CACHE_MAX_MB). TULPAR_AOT_NOCACHE=1 disables it, tulpar cache clean empties it, TULPAR_CACHE_RAPOR=1 prints each hit/miss decision. Web/Android targets, --debug and --sanitize builds always compile.

tulpar debug is a bridge to gdb (MI3), so gdb must be on PATH: your distro's package on Linux (apt install gdb, pacman -S gdb), pacman -S mingw-w64-x86_64-gdb in an MSYS2 MINGW64 shell on Windows. There is no lldb backend yet — on Apple Silicon build with tulpar --debug build x.tpr x and use lldb ./x directly. Without gdb, launch fails with that install hint instead of hanging. Values show decoded ("Hamza", [1, 2, 3], {"k": 7}) through an embedded gdb pretty-printer; for a plain gdb session, tulpar debug --gdb-script > t.py and (gdb) source t.py.

CLI output language follows the system locale — Turkish on TR machines, English everywhere else. Override with TULPAR_LANG=tr or TULPAR_LANG=en. The [typecheck] warnings always run as a build pre-pass; suppress with --no-typecheck or TULPAR_NO_TYPECHECK=1.

Build from source

Prerequisites: GCC or Clang, LLVM 18+, CMake 3.14+. Optional: OpenSSL (enables https:// for the HTTP client and wings_tls).

Linux / macOS:

./build.sh

Windows (MSYS2 MINGW64 shell):

pacman -S mingw-w64-x86_64-{gcc,clang,cmake,ninja,llvm,zlib,zstd,libxml2,openssl}
./build.sh

(There is no build.ps1 / build.bat; CI's build-windows job builds the same way.)

Direct CMake (incremental):

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build -j

build.sh wipes the build directory each time. For incremental rebuilds during development, use CMake directly. The output is a tulpar (tulpar.exe on Windows) copied to the repo root plus libtulpar_runtime.a linked by AOT-compiled user binaries.

Language at a glance

// Static types with inference
int x = 42;
float pi = 3.14159;
str name = "Tulpar";
bool active = true;

// Number literals
int hex = 0xFF;     // 255
int oct = 0o755;    // 493
int bin = 0b1010;   // 10

// First-class JSON
json user = {
    "name": "Ali",
    "age": 30,
    "address": { "city": "Istanbul" }
};
print(user.address.city);  // dot access works

// Custom types — int/bool/float fields are unboxed (native LLVM structs)
type Person {
    str name;
    int age;
}
Person p = { name: "Ali", age: 25 };
struct Vec3 { float x; float y; float z; }
Vec3 v = { x: 1.5, y: 0, z: -2 };   // {double, double, double}, zero heap

// Typed struct arrays — elements stored contiguously, unboxed
struct Enemy { int id; int hp; float x; float z; }
Enemy[] enemies = [];
push(enemies, Enemy_new(1, 0.0, 0.0));
enemies[0].hp = enemies[0].hp - 34;   // pointer + GEP, no key lookup

// Multiple return values — a synthesized unboxed struct under the hood
func polar(float x, float y): (float, float) { return sqrt(x*x + y*y), atan2(y, x); }
float r, theta = polar(3.0, 4.0);
r, theta = polar(1.0, 0.0);

// Enums — named integer constants, folded at parse time (zero runtime cost)
enum Screen { MENU, GAME, PAUSED = 5, SETTINGS }   // 0, 1, 5, 6
Screen s = Screen.MENU;                             // Screen is an int
str label = match s { Screen.MENU => "menu", _ => "other" };

// Control flow
for (int i = 0; i < 10; i++) { print(i); }

// Error handling
try {
    risky();
} catch (e) {
    print("Error: " + toString(e));
} finally {
    cleanup();
}

// Threading
int mu = mutex_create();
func worker(json arg) {
    mutex_lock(mu);
    // critical section
    mutex_unlock(mu);
}
int t = thread_create(worker, 42);
thread_detach(t);

Full guide at https://tulparlang.dev/guide/syntax/ · single-page language reference at https://tulparlang.dev/reference/language/.

Standard library

All modules below are embedded in the binary — import "name" just works, no package install required.

Module	Purpose
wings	HTTP server — sync, async, pool, and evented listeners
wings_tls	HTTPS server with OpenSSL — same handler API as wings
tulpar_api	FastAPI-style routing & JSON envelopes on top of Wings
router	Express-style URL routing & middleware
http_utils	HTTP request parsing & response building primitives
http_client	Outbound HTTP/HTTPS — http_get, http_post_json, …
middleware	Built-in middleware (logger, CORS, auth, rate-limit)
socket	TCP socket wrappers + poll / non-blocking helpers
async	setTimeout / setInterval / promise scaffolding
orm	SQLite ORM — define_model, orm_create, orm_where
test	Jest-style assertion framework + suite runner

Native built-ins (no import needed):

Category	Functions
I/O	print, input, inputInt, inputFloat
Type conversion	toInt, toFloat, toString, toBool
Math	abs, sqrt, pow, mod, sin, cos, tan, log, exp, floor, ceil, round, random, randint, min, max
String	length, upper, lower, trim, split, join, replace, substring, contains, startsWith, endsWith, indexOf
Regex	regex_match, regex_search, regex_capture, regex_replace
CSV	csv_parse, csv_emit
Array / object	push, pop, length, range, keys
JSON	toJson, fromJson, parse_cookies
Date / time	timestamp, time_ms, now_iso8601, format_iso8601, parse_iso8601, weekday, date_add_seconds, clock_ms, sleep
File	file_read, file_write, file_exists, file_delete, file_append, file_glob
Process / env	env, exit
Sockets	socket_server, socket_client, , , , , ,

Architecture

TulparLang/
├── src/
│   ├── lexer/          # Tokenization
│   ├── parser/         # Recursive-descent parser, AST nodes
│   ├── typeinfer/      # Type inference (build pre-pass)
│   ├── aot/            # LLVM AOT backend (the only execution path)
│   ├── vm/             # Shared runtime: aot_* builtins, arena allocator, value types
│   ├── lsp/            # Language Server Protocol
│   ├── fmt/            # Source formatter
│   ├── pkg/            # Package manager (tulpar.toml + lockfile)
│   ├── cli/            # Subcommands (update, etc.)
│   └── common/         # Localization, version, platform shims, TLS plumbing
├── lib/                # Standard library (Tulpar source, embedded at build)
├── runtime/            # cJSON, arena heap, native FFI
├── examples/           # 47 example programs
├── benchmarks/         # Multi-language benchmark suite (CPU + HTTP)
├── tests/              # Smoke tests + lib/test.tpr regression suites
├── installer/          # Inno Setup script for Windows installer
├── wasm/               # WebAssembly target (separate build)
└── cmake/              # CMake modules + EmbedLibraries.cmake

Execution model

Tulpar follows the C/Rust/Go model — a single AOT/LLVM execution path. tulpar <file> AOT-compiles and runs; there is no VM fallback, so an AOT failure is a hard error.

Component	Role
AOT (LLVM)	The only execution path. LLVM IR → native via clang.
src/vm/ runtime	Shared runtime linked into AOT'd binaries (the aot_* builtins, arena allocator, value types) — not an interpreter.

The bytecode VM interpreter and the REPL were removed in v3.0.0 (2026-06-15); --vm/--run are ignored with a warning and --repl prints a removal notice. The legacy tree-walk interpreter and x64 JIT were retired earlier, in May 2026. See STATUS.md.

Examples

Dozens of example programs live in examples/. A few highlights:

File	Demonstrates
01_hello_world.tpr	Basic syntax, types, arithmetic
06_data_structures.tpr	Arrays + JSON
10_try_catch.tpr	Error handling
12_threaded_server.tpr	Threaded HTTP server
13_database.tpr	SQLite via the built-in db_* API
api_wings_crud.tpr	REST CRUD on top of Wings
api_wings_sse.tpr	Server-Sent Events via the streaming dispatcher
32_wings_ws_frames.tpr	WebSocket send/recv frame round-trip
31_crypto_sse_ws.tpr	sha1 / base64 / WS accept-key + SSE formatting
tulpar_api_demo.tpr	Full TulparAPI app with middleware
benchmark.tpr	The fib / loopsum benchmark workloads

Run any of them with tulpar examples/<file>.tpr.

Documentation

Full docs (Türkçe & English) at https://tulparlang.dev.

Quick links:

• Getting Started — install + first program
• Language Reference — single-page lookup
• Wings HTTP Server — listener API + routing
• Package Manager — tulpar.toml, lockfile, semver ranges
• CLI Reference — every flag and subcommand

Local docs in this repo:

• docs/PLATFORM_SUPPORT.md — per-OS prerequisites, build steps, troubleshooting
• RELEASING.md — how stable releases are cut
• STATUS.md — current shipping status + open gaps

Contributing

1. Fork the repository
2. Create a feature branch (git checkout -b feature/name)
3. Commit your changes
4. Push to the branch
5. Open a Pull Request

Issues and design discussions welcome at https://github.com/hamer1818/TulparLang/issues.

License

MIT — see LICENSE.

Author

Hamza Ortatepe · @hamer1818

---

Site · Docs · Examples · Releases · Issues