From source to a running program
Today we will write the smallest useful Tinox program and follow it all the way to a native executable. The result is intentionally simple: Hello, Tinox, printed in the terminal. A simple result lets us focus on structure. By the end, you should know where a project starts, why the entry class is called Main, how to build and run it, and how to read a basic compiler error without losing your place.

Create the project skeleton
Tinox new creates a project directory, a package manifest, a source directory, and a starter test. Run it from the parent directory, then enter the generated project. The captured output shows that actual scaffold operation. In this frozen snapshot, the generated manifest repeats the compiler key. The companion example contains the same essential project structure with that duplicate removed. Keep only one compiler field in the package table, as shown in the next scene.

Read the minimal manifest
The package section gives this project a name and version. The compiler field states the exact Tinox version expected by the project. The entry field selects the source file used to start a normal build or run. These are different kinds of version information: the application version does not have to equal the compiler version. We are not adding dependencies yet. This example uses the basic language and builtin output function, so we can stay focused on the entry program.

The filename and the class agree
Create Main dot t n x under source and declare class Main. Tinox requires at most one top level type declaration per file, and the filename must match the type name. That makes the relationship between files and types explicit. Our entry class therefore belongs in Main dot t n x, with exactly that capitalization. Later, a controller called Hello Controller will live in its own file, rather than being added as a second class below Main.

Declare the static entry method
Inside the class, add f n c main, with no parameters, returning Int thirty two. In Tinox, f n c declares a static method. It belongs to the type and does not need an instance object. The ordinary application entry point uses this class and method shape. Later, we will use f n for instance methods, which operate through an object. For this first example, keep the method inside the braces of Main and keep its return type explicit.

Print the greeting
Add a call to println before the return. The quoted characters form a string literal. Print line writes that string to standard output and ends the line. Notice the nesting: the print call is inside the method, and the method is inside the class. Statements end at the line boundary in the syntax used here. We do not append semicolons to these statements. Keep the source close to the example while learning the basic shape.

Return success to the operating system
The final return sends zero back as the program's exit status. That is different from printing the number zero. Standard output carries text that a person or another program can read. The exit status is a separate value used by shells and other tools to decide whether a command succeeded. Our program prints one greeting, returns success, and finishes. Making that distinction now will help when we later automate tests and run applications in containers.

Build an executable
From the project root, call Tinox build and choose hello as the output name. The compiler reads the manifest and entry source, checks the program, and builds the native executable. The captured completion message reports success. If the command fails, read its diagnostic before trying to run the expected file. A file left over from an earlier successful build would not prove that the current source is valid.

Run the resulting file
Now execute dot slash hello. The shell runs the compiled program, and we see the greeting. We are no longer asking the Tinox command to interpret the source line by line. The program is a native executable built from that source. Its environment still matters, including shared libraries discussed in the introduction. For everyday development, Tinox run combines building when needed and executing, so you can choose the workflow that matches what you are checking.

Read a deliberate error
Change println to printline, adding an extra e, and run Tinox check. The compiler reports an undefined function and points to the source location. The important parts are the filename, the line, and the message. Return to that location and compare the spelling with the working source. In a larger program there may be several messages, but fixing the first relevant mistake often makes later messages easier to understand.

A small exercise
Restore println and change the text to a greeting of your own. Run it with Tinox run, then build another executable and start it directly. You should get the same visible result from the same source. As a second check, remove the print call while keeping return zero. The program should then finish successfully without a greeting. That experiment reinforces the difference between producing output and returning an exit status.

What we can now explain
You now have a small but complete chain: a manifest selects an entry file, the file declares Main, and its static main method prints text and returns an exit status. We have also seen one real diagnostic and repaired it. Keep the working project as a reference. In the next episode, we will replace the fixed greeting with named values, calculate a small price, and use the type system to catch an invalid change before running the program.
