A small endpoint. A real response.
A few lines of Tinox can describe an HTTP endpoint and return a real JSON response. The code on screen was compiled and tested against curl, an independent HTTP client. That gives us a useful starting point for this series: a small program whose behavior we can actually inspect. Before we type every line, let us understand what Tinox is, what it offers, and what you will learn to build.

What is Tinox?
Tinox is a statically typed programming language that compiles to native code through an LLVM backend. It includes a runtime, automatic garbage collection, and support for concurrent work. In practical terms, you write source files, ask the compiler to check and build them, and run the resulting executable. These are separate steps. A successful build tells us something about the program, but we still run tests to check what it does.

Benefit 1: catch mistakes early
Static types give names to the kinds of values a program expects. An integer and a string are different types, even when the string contains digits. Here, the variable expects an integer, but the initializer is text. Tinox rejects that mismatch before the application starts. This is useful feedback while you are changing code. It does not mean that every possible bug is caught by the compiler. Logic errors and failures in external systems still need testing.

Benefit 2: describe the wiring
For supported features, annotations let you describe how a class or method participates in an application. In this controller, Get selects the HTTP method, and Path selects the URL. We write the method that produces the result, and Tinox generates the corresponding route wiring. This keeps a small example readable. Later, we will inspect that generated wiring with compiler tools, so the convenience does not have to remain a mystery.

Benefit 3: a connected workflow
The compiler command also provides an everyday development workflow. We can create a project, check it, build it, run it, and execute tests. Other commands help with formatting, documentation, packages, and understanding resolved APIs. You do not need to learn every command immediately. In the first six episodes, we will use a small, repeatable subset, and introduce each command when it solves a problem in front of us.

Native does not mean dependency-free
A native executable runs as machine code for its target environment. That can make deployment feel familiar if you already work with ordinary Linux programs. But native does not automatically mean a completely self-contained static file. Tinox applications use a runtime and may depend on shared libraries. We will inspect those dependencies when we discuss builds and containers. For now, think of the executable and its runtime environment as parts of the same working application.

Automatic memory management
Garbage collection handles the reclamation of ordinary managed objects, so most application code does not manually free them. That removes one kind of bookkeeping from everyday programming. It does not automatically make shared mutable state safe between threads, and it does not promise perfectly predictable timing. Those are different concerns. When our examples become concurrent, we will introduce synchronization and explain the actual runtime model rather than treating the word asynchronous as a guarantee.

A small application will grow
Our course project will be a small task board. We will begin with values and functions, add an HTTP API, and later store tasks in a database. After that, we can add identity, live updates, a browser interface, and deployment. This picture is a course roadmap, not a claim that the finished task board already exists. Each step will have a working example that you can run without requiring infrastructure from later episodes.

A clear platform and version
Tinox deliberately targets Linux. This course uses a frozen source snapshot for compiler version two point nine point five, together with matching companion packages. The materials record that exact snapshot. The language is still developing, so older examples and newer compilers may differ. Keeping the compiler and package versions together makes the lessons easier to reproduce, and lets us talk about current behavior without turning a tutorial into an unsupported compatibility promise.

Who is this course for?
You should be comfortable with the idea of variables, functions, and a terminal. You do not need prior experience with Tinox, Java, Rust, or LLVM. We will explain Tinox syntax as it appears, use real compiler output, and include failures as well as successes. Pause when you want to try a change. The goal is to understand why the program works, not just to watch text appear on screen.

Your first learning path
The next episode prepares the tools and the editor. Then we write Hello World, learn types and variables, and combine conditions, loops, and functions. In episode six, we return to this endpoint and build it from its individual files. After those six lessons, you will have both a working command line program and a small web service. For now, choose one thing you would like that future task board to do. We will keep that goal in mind as the code grows.
