Was ist Tinox?

Tinox ist eine eigenständig entwickelte, statisch typisierte Programmiersprache, die direkt zu nativen Maschinenbefehlen kompiliert wird. Die Sprache kombiniert eine Java-ähnliche, annotation-getriebene Syntax mit den Leistungsvorteilen eines LLVM-basierten Compilers und einem in C geschriebenen Laufzeitsystem.

Der Hauptfokus liegt auf der einfachen Entwicklung hochperformanter HTTP-REST-Dienste: Ein Controller-Handler benötigt nur wenige Zeilen Code, und der eingebaute HTTP-Server basiert auf epoll und SO_REUSEPORT – Technologien, die auch in produktionsreifen Webservern wie Nginx eingesetzt werden.

import tinox.core.http_server
import tinox.core.json

class SortController
{
    @POST
    @Path("/sort")
    @Consumes(MediaType.APPLICATION_JSON)
    @Produces(MediaType.APPLICATION_JSON)
    fn sort(ctx: HttpContext) -> Nothing
    {
        const root: JsonValue = Json.parse(ctx.request.body)
        const numbers: List<Int64> = Json.intArrayFromJson(root.getField("numbers"))
        ctx.response.body = Json.intArrayWrap("sorted", numbers.sort())
    }
}

Dieser Code stellt einen vollständig funktionsfähigen REST-Endpunkt dar – kein Framework-Konfigurationsaufwand, keine XML-Dateien, kein Boilerplate.

Technische Grundlagen

LLVM als Compiler-Backend

Der Tinox-Compiler erzeugt keine nativen Maschinenbefehle direkt, sondern LLVM Intermediate Representation (LLVM IR) – eine plattformunabhängige, typisierte Assemblersprache. Das LLVM-Toolchain übernimmt dann die Optimierung und Übersetzung in Maschinencode.

LLVM wird auch von Clang (C/C++), Rust, Swift, Julia und Kotlin Native verwendet – es ist eines der ausgereiftesten Compiler-Backends der Industrie.

Rust als Implementierungssprache

Der gesamte Compiler – Lexer, Parser, Typchecker, Codegenerator und LSP-Server – ist in Rust implementiert. Das bringt folgende Vorteile:

• Sicherheit Kein Undefined Behavior, keine Speicherfehler im Compiler selbst
• Performance Schnelle Compile-Zeiten des Compilers (keine GC-Pausen)
• Parallelität Thread-sichere Datenstrukturen (DashMap) für den LSP-Server

C als Laufzeitsystem

Das Laufzeitsystem (runtime.c) ist in C geschrieben und stellt alle Betriebssystem-nahen Funktionen bereit: Speicherverwaltung, Strings, Arrays, Maps, Datei-I/O, Netzwerk und den HTTP-Server. C-Funktionen werden direkt aus dem LLVM IR heraus aufgerufen – kein ABI-Overhead durch Wrapper-Schichten.

Wichtige Konzepte

Anweisungsende

Eine Anweisung endet am Zeilenende – es gibt kein Terminatorzeichen. Ein ;, das eine Anweisung beendet, ist ein harter Compilerfehler („semicolons were removed“); mehrere Anweisungen in einer Zeile sind nicht möglich. Das einzige verbleibende ; trennt die Teile eines C-artigen for (init; cond; update)-Kopfes.

Eine Anweisung geht in der nächsten Zeile nur weiter, wenn die Zeile mit einem binären Operator, einem Komma oder einer öffnenden Klammer endet oder die nächste Zeile mit . beginnt (Methodenketten). Innerhalb von ( ) und [ ] sind Zeilenumbrüche normale Leerzeichen. Eine Zeile, die direkt nach einem vollständigen Ausdruck mit (, [, - oder + beginnt, ist ein harter Fehler – der Compiler rät nie, ob sie die vorige Zeile fortsetzt. Enum-Varianten stehen je eine pro Zeile.

const total = first +
    second +
    third

const name = user
    .profile()
    .displayName()

Komponenten-Übersicht

Tinox besteht aus mehreren Rust-Crates (Bibliotheken), die zusammen den Compiler und das Tooling bilden, plus dem C-Laufzeitsystem und der in Tinox selbst geschriebenen Standardbibliothek.

Compiler-Pipeline

Der Tinox-Compiler transformiert eine .tnx-Quelldatei in mehreren Schritten zu einem ausführbaren nativen Binary:

Runtime (C-Laufzeitsystem)

Das Herzstück des Tinox-Laufzeitsystems ist runtime/runtime.c (~1.700 Zeilen C-Code). Es stellt alle Primitive bereit, auf die der generierte LLVM IR direkt zugreift.

Speicherverwaltung

Tinox verwendet den Boehm Garbage Collector (libgc) für automatisches Speichermanagement. Der GC ist konservativ: Er scannt Stack und Register nach Zeigern und gibt nicht mehr erreichbare Objekte frei – ohne dass der Entwickler explizit free() aufrufen muss. Durch GC_THREADS ist er vollständig thread-sicher und funktioniert korrekt mit dem epoll-basierten HTTP-Server-Thread-Pool.

Für häufige Operationen (Sort, JSON-Parsing) werden thread-lokale statische Puffer verwendet, die einmal alloziert und dann wiederverwendet werden – das eliminiert den malloc-Overhead im Request-kritischen Pfad komplett.

Collections

Async & Concurrency

Das Concurrency-Modell basiert auf POSIX-Threads (pthreads). spawn erstellt einen echten OS-Thread. Channels nutzen intern eine Linked-List-Queue mit Mutex und Condition Variable.

Task-Lebensdauer, Deadlines und Abbruch

scope { ... } besitzt seine lexikalischen Spawns. Ein einfacher Spawn gehört zur Lebensdauer seines erzeugenden Threads; dieser wartet vor seinem Ende auf übrige Kinder. Beim Prozessende werden verbleibende joinbare Kinder abgebrochen und eingesammelt. Fehler werden durch await oder unbeobachtet am Scope-Ende weitergereicht; weitere Fehler erscheinen auf stderr. Der eigene Fehler des Blockrumpfs hat Vorrang. Wiederholtes Await liefert innerhalb der Lebensdauer denselben Wert oder Fehler. Nach Ende des besitzenden Scopes sind Handles ungültig; weitere Verwendung scheitert sichtbar. Tasks bleiben beim Besitzer; nach außen sollte der bereits erwartete Ergebniswert zurückgegeben werden.

try {
    scope {
        taskSetDeadline(250) // Duration from now, in monotonic milliseconds.
        const task: Task<String> = spawn Main::load()
        println(await task)
    }
} catch (e: String) { println(e) }

Abbruch weckt auch sleep/sleep_ms, blockiertes Channel-recv und await (Prüfintervall etwa 10 ms, zuzüglich Scheduling). Tokens werden an Kind-Tasks und innere Scopes vererbt. Scope-Fehler brechen übrige Geschwister ab; der Fehler des Rumpfs bleibt vorrangig. Ein explizit abgebrochener Task meldet den Abbruch weiterhin, sofern er nicht per Await abgefangen wurde. Erwarteter Abbruch beim Prozessende gilt als erfolgreich.

Abbruch verwendet normales Exception-Unwinding: finally und defer laufen in der üblichen Reihenfolge; eine Transaktion im Kind wird vor Abschluss des Joins zurückgerollt. Transaktionen sind thread-lokal und werden nicht vererbt. Ein Scope innerhalb einer transaktionalen Methode wartet vor dem Commit auf Kinder. Ressourcen des Elternthreads sollten außerhalb des Scopes aufgeräumt werden, damit Kinder zuerst fertig werden.

Es gibt keine asynchrone Thread-Terminierung. Native blockierende I/O, Datenbankaufrufe und CPU-Schleifen ohne Prüfpunkt sind nicht automatisch unterbrechbar. Ressourcenspezifische Stopp-/Close-Operationen oder taskWaitReadable verwenden. Nach fünf Sekunden ignoriertem Abbruch beim Scope-Ende scheitert die Runtime sichtbar statt still zu hängen. Ein explizites Await eines abgebrochenen Tasks und eine Service-Stoppanforderung haben dieselbe Fünf-Sekunden-Grenze. Mit @Service gilt stattdessen das gemeinsame konfigurierte Shutdown-Budget; siehe den Service-Lebenszyklus unten. Abgekoppelte Worker werden ausdrücklich nicht strukturiert eingesammelt.

Speichern und Await bisheriger Int64-Handles bleiben für veröffentlichte Pakete vorübergehend kompatibel. Neuer Code und die Task-Steueroperationen verwenden Task<T>. Ungültige/abgelaufene Handles und zyklische Awaits scheitern mit Diagnose; Integer-Handles sind veraltet.

Koordinierter Service-Lebenszyklus

@Service(startupMs, shutdownMs) auf class Main aktiviert koordinierten Start, Health-Status und geordnetes Herunterfahren. Beide Angaben sind optionale positive Millisekunden (Standard: 30000 und 5000; Maximum: 3600000). Der Koordinator startet vor Datenbankinitialisierung und eager DI.

@ApplicationComponent
@Synchronized
class Resources {
    @OnStart
    fn start() -> Nothing { /* Initialize resources before listeners start. */ }
    @Readiness
    fn ready() -> Bool { return true }
    @Liveness
    fn live() -> Bool { return true }
    @OnStop
    fn stop() -> Nothing { /* Dispose resources after callbacks and tasks finish. */ }
}

@Service(30000, 5000)
class Main {
    fnc main() -> Int32 { return 0 }
}

Komponente und annotierte Controller/Endpoints aus der Einstiegsdatei importieren. Hooks sind synchrone Instanzmethoden ohne Parameter auf nichtgenerischen @ApplicationComponent/@Startup-Klassen ohne Vererbung. Start-Hooks folgen den injizierten Abhängigkeiten, danach Klassen-/Methodennamen; Stop-Hooks laufen umgekehrt. Jeder Hook joint seine gestarteten Kinder vor dem nächsten Schritt. Auch nach Startfehlern erhalten initialisierte Besitzer ihre Stop-Hooks. Cleanup läuft trotz Fehlern weiter; der erste Fehler bleibt erhalten, der Prozess endet mit Fehlerstatus. Gemeinsamen veränderlichen Zustand mit @Synchronized schützen.

Zustände: initializing → starting → ready, bei negativem Health-Beitrag unready, anschließend draining → stopping → stopped oder failed. Readiness verlangt abgeschlossene Initialisierung/Start-Hooks, gebundene Listener, Consumer-Handshakes und positive Readiness-/Liveness-Beiträge. Main ist keine Readiness-Barriere: Mit Listenern läuft der Dienst nach seiner Rückkehr weiter; ohne Listener fordert die Rückkehr das Herunterfahren an.

Generierte HTTP-/HTTP/3-Server reservieren GET /health/live und GET /health/ready: Status 200 oder 503 mit JSON für Zustand, Readiness, Liveness und monotone Zeitstempel startedMs, readyMs, shutdownMs. Start meint den Eintritt in den verwalteten Bootstrap, Ready den ersten erfolgreichen Health-Durchlauf, nicht Prozessstart oder Banner. Health-Methoden laufen regelmäßig im Koordinator und sollten kurz bleiben. Überschrittenes Startbudget beendet den Prozess sichtbar; spätere negative Health-Ergebnisse ändern den Status, starten den Prozess aber nicht neu.

serviceState(), serviceStatusJson(), serviceIsReady(), serviceIsLive(), serviceIsStopping() und serviceStartedMs()/serviceReadyMs()/serviceShutdownMs() liefern denselben Status. serviceAwaitReady(ms) liefert Bool; serviceBoundPort(index) den tatsächlichen Port eines Auto-Run-Tasks in Bootstrap-Plan-Reihenfolge (-1 vor Bind oder bei Brokern). tinox explain --bootstrap Main.tnx --json zeigt Budgets, Hook-Reihenfolge, Tasks und Shutdown-Vertrag.

SIGTERM, SIGINT, serviceRequestShutdown() und taskRequestShutdown() setzen den Dienst auf unready und stoppen neue Arbeit. Angenommene HTTP-Antworten und Broker-Bestätigungen werden beendet; WebSockets senden Close-Code 1001 und rufen OnClose auf. Listener und Worker werden gejoint, danach übrige strukturierte Kinder abgebrochen/gejoint, Stop-Hooks umgekehrt ausgeführt und Datenbank-Pools geschlossen. serviceAwaitShutdown() lässt Main auf die Stop-Anforderung warten. Ein gemeinsames Shutdown-Budget umfasst alle Schritte; bei Ablauf endet der Prozess mit Status 1, auch bei blockierendem nativen I/O oder Hooks. Keine asynchrone Thread-Terminierung; explizit detached gestartete Benutzer-Tasks bleiben außerhalb des strukturierten Join-Vertrags.

Container mit Exec-Entrypoint starten, damit Signale tinox erreichen. Startup-, Readiness- und Liveness-Probes auf die Health-Pfade richten; die Termination-Grace-Period muss länger als das Shutdown-Budget sein. @Command und @TinoxUIApp lassen sich derzeit nicht mit @Service kombinieren; der Compiler meldet dies als Fehler.

Gemeinsamer Anwendungszustand

@ApplicationComponent erzeugt pro Komponentenklasse einen lazy Singleton; @Startup erzeugt denselben Singleton-Typ vor main. Generierte Provider synchronisieren Erzeugung, Feld-Defaults, rekursive Dependency Injection und Veröffentlichung. Gleichzeitige Provider-Aufrufe erhalten dieselbe vollständig initialisierte Instanz. Benutzerkonstruktoren werden dabei nicht aufgerufen. Spätere Änderungen werden dadurch nicht gesperrt.

HTTP-Worker sowie unabhängig gestartete REST-, WebSocket- und AMQP-Komponenten können gleichzeitig laufen. Request-Daten gehören in @HttpRequestScoped-Besitzer, in die Anwendungsservices injiziert werden. Eine Request-Abhängigkeit in einem Singleton wird geteilt; das Erneuern eines injizierten Feldes im Singleton-Controller beim Dispatch bietet keine sichere Request-Isolation. Der Compiler warnt vor solchen Abhängigkeiten sowie öffentlichen oder ungeschützten veränderlichen Singleton-Feldern.

@ApplicationComponent
@Synchronized
class Counter {
    private var value: Int64 = 0
    fn increment() -> Int64 {
        this.value = this.value + 1
        return this.value
    }
}

@HttpRequestScoped
class Api {
    @Inject var counter: Counter
    @GET @Path("/count")
    fn count() -> Int64 { return this.counter.increment() }
}

@Synchronized an einer nicht-generischen Application-/Startup-Klasse schützt alle Instanzmethoden; an einer Instanzmethode nur diese Methode. Es gibt einen rekursiven Monitor pro deklarierender Klasse, den alle markierten Aufrufe und Instanzen dieser Klasse teilen. Verschachtelte Aufrufe desselben Threads sind erlaubt. Statische Methoden sind bei der Klassenannotation ausgenommen; explizit markierte statische/generische Methoden, Klassen ohne Singleton-Scope, Interface-/Trait-Methoden und Klassen mit Vererbung werden zurückgewiesen.

Der Monitor bleibt während defer/finally und Transaktions-Commit/Rollback gehalten und wird vor Rückgabe eines Werts oder Fehlers freigegeben. Abbruch beim Warten auf den Monitor wirft ohne Ausführung des Rumpfs. Abbruch im Rumpf führt das normale Unwinding und die Freigabe aus. Bereits aktive Fehler bleiben beim Aufräumen erhalten. Dev-UI-Zustandssnapshots nutzen den Klassenmonitor, sofern vorhanden.

Zustand privat halten und sowohl Lesen als auch Schreiben schützen. Zurückgegebene veränderliche Objekte, direkte Feldzugriffe sowie statische und unmarkierte Methoden umgehen den Monitor. Snapshots innerhalb einer geschützten Methode erstellen, statt interne Collections zurückzugeben. Unter gehaltenem Monitor kein Kind awaiten, das denselben Monitor benötigt; verschiedene Klassenmonitore in einheitlicher Reihenfolge betreten. Rekursion gilt für einen Thread, nicht für gespawnte Kinder. Für kleinere explizite kritische Abschnitte können Locks aus tinox.core.semaphore mit unmittelbar nach erfolgreicher Sperre registriertem defer dienen; diese nativen blockierenden Locks werden nicht abbrechbar. Annotationen und Diagnosen sind kein allgemeiner Beweis für Race-Freiheit.

HTTP-Server (Low Level)

Der HTTP-Server im Runtime verwendet:

• SO_REUSEPORT Mehrere Threads binden den gleichen Port – der Kernel verteilt Verbindungen
• epoll Event-Multiplexing: ein Thread verwaltet bis zu 4.096 gleichzeitige Verbindungen
• TCP_NODELAY Nagle-Algorithmus deaktiviert – sofortiges Senden kleiner Pakete
• Keep-Alive HTTP/1.1 keep-alive, Idle-Timeout 500ms

Typsystem

Primitive Typen

s.chars() liefert List<String> mit einem Unicode-Skalarwert pro Element. Mit for ch in s.chars() lassen sich vollständige UTF-8-Zeichen verarbeiten. Kombinierende Zeichen und Emoji-Sequenzen können mehrere Elemente umfassen; Normalisierung und Graphemsegmentierung finden nicht statt. Leere Eingabe liefert eine leere Liste; ungültiges UTF-8 bricht mit dem Byte-Offset ab. Länge, Indizierung, charAt und direkte String-Iteration behalten ihre Byte-Semantik. Der Aufruf benötigt O(Bytes) Zeit und reserviert eine Liste sowie einen kurzen String pro Skalarwert.

Zusammengesetzte Typen

const numbers: List<Int64> = [1, 2, 3]                 // Array
const ages: Map<String, Int32> = @{"Alice" => 30}  // Map/Dictionary
const pair: (Int32, String) = (42, "hello")           // Tuple
const name: String? = null                             // Nullable
const fn add: fn(Int32, Int32) -> Int32 = |a, b| a + b // Funktionstyp

Generics

Tinox unterstützt parametrische Polymorphie mittels Monomorphisierung: Für jede konkrete Typisierung wird eine eigene Funktion erzeugt – wie in C++ Templates oder Rust. Es gibt keinen Laufzeit-Overhead durch Typ-Erasure (wie in Java).

fn max<T>(a: T, b: T) -> T
{
    if a > b { return a }
    return b
}

class Box<T>
{
    var value: T
}

Objektorientierung

Tinox ist eine hybride Sprache – objektorientiert mit Klassen, Vererbung und Interfaces, aber auch prozedurale freie Funktionen und funktionale Konzepte (Lambdas, Higher-Order Functions) sind möglich.

Klassen

class Animal
{
    var name: String
    var age:  Int32

    fn speak() -> String        // Instanzmethode
    {
        return "..."
    }

    fnc create(name: String) -> Animal  // statische Methode (fnc)
    {
        return Animal { name: name, age: 0 }
    }
}

class Dog extends Animal       // Vererbung
{
    fn speak() -> String
    {
        return "Wuff!"
    }
}

Interfaces & Polymorphismus

interface Serializable
{
    fn serialize() -> String
}

class User implements Serializable
{
    var name: String

    fn serialize() -> String
    {
        return "User:" + this.name
    }
}

Interface-Dispatch wird über Vtables implementiert – identisch zu C++ virtuelle Funktionen. Jedes Objekt, das ein Interface implementiert, bekommt einen Zeiger auf eine Tabelle von Funktionszeigern.

Abwesenheit und behandelbare Fehler

Neue Bibliotheks-APIs verwenden Option<T> für fehlende Werte und Result<T> für erwartete Fehler. Die Imports sind tinox.core.option und tinox.core.result. Some("") bedeutet vorhanden, aber leer; None bedeutet nicht vorhanden. Mit isSome()/isNone() prüfen oder mit unwrapOr() einen Ersatzwert wählen. Keine zusätzliche nullable T?-Variante derselben Suche einführen.

Result<T> behält seinen String-Fehler. Status mit isOk()/isErr() prüfen und Details über getError() lesen. Operation, Ziel und Ursache ohne geheime Daten erhalten; den Status nicht aus dem Meldungstext ableiten. Stabile Fehlerkategorien gehören in dokumentierte Ergebnisfelder. Ein generisches Result mit Fehlertyp und Änderungen der Speicherbelegung bleiben separater Arbeit vorbehalten.

Exceptions bleiben für dokumentierte Vorbedingungen, Programmier- und Einrichtungsfehler geeignet. Option.unwrap() wirft bei None "Option is None"; Result.unwrap() wirft bei Err den ursprünglichen Fehler. Exceptions aus Callbacks werden weitergereicht. finally dient der Bereinigung bei normalem und fehlerhaftem Verlassen eines Blocks.

Die ergänzenden HTTP-Methoden findHeader, findParam, findQuery und QueryString::find liefern Option<String>. Header ignorieren Groß-/Kleinschreibung, Pfad- und Query-Namen unterscheiden sie. Query-Werte bleiben roh; der letzte doppelte Parameter gewinnt, ein Schlüssel ohne Wert ist vorhanden und leer. Bestehende String-Getter behalten ihren leeren Ersatzwert ohne Deprecation-Warnungen. Eine Paketversion mit den optionalen Methoden oder zusammenpassende Workspace-Quellen verwenden. Beispiele und bestehende I/O-Grenzen stehen im API-Inventar und Migrationsleitfaden.

Der aktuelle Quellstand bietet außerdem geprüfte Dateisystem-Alternativen: Fs::tryReadFile, tryWriteFile, tryAppendFile, tryCopyFile, tryMoveFile und tryDeleteFile. Ihr IoResult<T> enthält Status und Nutzwert zusammen; failure() liefert Operation, Ziel, Betriebssystemcode und Ursache. Eine leere Datei ist ein Erfolg; Teil-Lesefehler und fehlgeschlagenes abschließendes Schreiben sind Fehler. Migration und Kompatibilität.

ByteStream und Http1Stream bieten begrenztes TCP-/TLS-Streaming mit Zeitlimits, expliziter Ressourcenübernahme und Bereinigung. HTTP/1.1-Streaming unterstützt einen Austausch mit Content-Length; die HTTP/2-/HTTP/3-Brücken erhalten Binärdaten, puffern aber weiterhin ganze Bodies. Binärdaten- und Streaming-Verträge.

Schlüsselwort-Übersicht

Annotationen

Das Annotationssystem ist eine der zentralen Stärken von Tinox. Annotationen steuern das Verhalten des Compilers, des HTTP-Servers und zukünftiger Frameworks – ähnlich wie in Java/Spring oder Quarkus.

HTTP-REST-Annotationen

Jeder Parameter eines @GET/@POST/…-Handlers braucht genau eine Bindungs-Annotation: @PathParam/@QueryParam binden per Parametername an das gleichnamige :name-Pfadsegment bzw. den Query-String-Key, @PostParam deserialisiert den kompletten JSON-Request-Body, @HttpContext gibt Zugriff auf Request/Response. Der Rückgabetyp entscheidet über den Antwortmodus: HttpContext bedeutet manueller Modus (die Methode baut ctx.response selbst auf), jeder andere Typ wird automatisch als JSON serialisiert.

// Auto-Serialize: Rückgabewert wird automatisch zu JSON
@GET
@Path("/users/:id")
@Produces(MediaType.APPLICATION_JSON)
@Auth("bearer")
fn getUser(@PathParam id: Int64) -> User { ... }

// Manueller Modus: dynamischer Statuscode (z.B. 404), @HttpContext + -> HttpContext
@GET
@Path("/users/:id")
fn getUserOrNotFound(@PathParam id: Int64, @HttpContext ctx: HttpContext) -> HttpContext
{
    // ... ctx.response.status(404).json(...) oder ctx.response.json(...)
    return ctx
}

Migration von der alten REST-API

Vor dieser Version bekam jeder Handler implizit genau einen ctx: HttpContext-Parameter ohne Annotation, mit Rückgabetyp Nothing, und musste Pfad-/Query-Parameter sowie den Request-Body manuell über ctx.request.getParam(...)/ctx.request.getQuery(...)/ Json::deserialize<T>(ctx.request.body) auslesen. Diese Form kompiliert nicht mehr — es gibt keine Abwärtskompatibilität, jeder Parameter braucht jetzt explizit eine der vier Bindungs-Annotationen.

Serialisierung

@JsonSerializable
class User
{
    var id:   Int64

    @JsonField("first_name")   // Überschreibt den JSON-Key
    var firstName: String

    @Sensitive              // Im Log als "***" ausgegeben
    var password: String

    @DoNotSerialize         // Nicht in JSON aufgenommen
    var internalToken: String
}

Alle eingebauten Annotationen

Aktuelle Verträge: DI-Provider und Request-Kontext, rekursive Request-Validierung und HTTP-400-Details.

Standardbibliothek (tinox-core)

Die Standardbibliothek besteht aus über 55 Modulen, die in Tinox selbst geschrieben sind. Import: import tinox.core.<modul>

LSP – Grundlagen

Das Language Server Protocol (LSP) ist ein von Microsoft im Jahr 2016 entwickeltes offenes Protokoll, das die Kommunikation zwischen einem Sprachserver (der die Programmiersprache versteht) und einem Editor (der die Benutzeroberfläche zeigt) standardisiert.

Das Problem vor LSP

Früher musste jede IDE für jede Sprache eigene Plugins implementieren: Eclipse-Plugin für Java, VS-Code-Plugin für Java, IntelliJ-Plugin für Java – alles separate Implementierungen der gleichen Logik. Bei n Sprachen und m Editoren entstanden n × m Integrationen.

LSP-Lösung: n + m statt n × m

Mit LSP schreibt man einmal einen Sprachserver, und jeder LSP-kompatible Editor nutzt ihn automatisch. Der Sprachserver kommuniziert über JSON-RPC über stdio mit dem Editor.

Editor (Eclipse, VS Code, Neovim …)
      │
      │  JSON-RPC über stdin/stdout
      ▼
Language Server (tinox-lsp Binary)
      │
      │  Analysiert .tnx-Dateien
      ▼
Lex → Parse → Typecheck → Antworten an Editor

Wichtige LSP-Methoden

Tinox LSP-Server

tinox-lsp ist ein vollständiger LSP-Server, implementiert mit tower-lsp 0.20 (Rust) und Tokio als asynchronem Laufzeitsystem.

Eingebettete Standardbibliothek

Alle 26+ Standardbibliotheks-Module sind mittels include_str!() direkt in das LSP-Binary eingebettet. Der Server benötigt keine Installation oder Konfiguration von Dateipfaden – er funktioniert sofort nach dem Kopieren des Binaries.

Import-Auflösung für Diagnostics

Wenn eine .tnx-Datei geöffnet wird, löst der LSP-Server automatisch import-Deklarationen auf und lädt die entsprechenden Stdlib-ASTs als Prelude. So werden Json.parse() oder HttpContext nicht als "undefined" markiert.

Dot-Completion für Klassen

Wenn der Nutzer Json. tippt:

1. Der Editor schickt textDocument/completion mit dem Offset nach dem Punkt
2. Der LSP extrahiert die Dot-Chain (["Json"])
3. Er prüft, ob Json eine Variable (Instanz) oder ein Klassenname ist
4. Falls Klassenname: direkt die Methoden von Json aus der Registry laden
5. Statische Methoden (fnc) werden mit dem Hinweis fnc parse(...) angezeigt

Technische Details

Eclipse-Plugin

Das Eclipse-Plugin tinox-eclipse verbindet den Eclipse IDE mit dem tinox-lsp Sprachserver über das LSP4E Framework – dem LSP-Client für Eclipse.

Features

Architektur

Das Plugin ist ein OSGi-Bundle, das über plugin.xml die .tnx-Dateiendung registriert und LSP4E anweist, bei geöffneten .tnx-Dateien den tinox-lsp-Prozess zu starten. Die Kommunikation läuft über stdin/stdout in JSON-RPC.

CLI-Werkzeuge

Das tinox-Binary ist das zentrale Werkzeug für alle Entwicklungsaufgaben:

HTTP-Server & Performance

Der integrierte HTTP-Server ist auf maximale Durchsatzrate bei minimaler Latenz optimiert. Er verwendet Technologien, die auch in produktionsreifen Systemen wie Nginx und Envoy eingesetzt werden.

epoll – Event-Multiplexing

Statt für jede Verbindung einen Thread zu blockieren, registriert der Server alle aktiven Verbindungen in einem epoll-Dateideskriptor. Ein epoll_wait()-Aufruf liefert alle Verbindungen, die lesebereite Daten haben – in einem einzigen Systemaufruf.

// Konzept (vereinfacht):
epoll_fd = epoll_create1(0)
// Alle aktiven Verbindungen registrieren...
while (true)
{
    events = epoll_wait(epoll_fd, max_events, 50) // 50ms Timeout
    for event in events
    {
        if event.fd == server_socket { accept() }
        else { handle_request(event.fd) }
    }
}

SO_REUSEPORT – Kernel Load Balancing

Mit SO_REUSEPORT können mehrere Threads (oder Prozesse) gleichzeitig auf demselben Port lauschen. Der Linux-Kernel verteilt eingehende Verbindungen automatisch auf die verfügbaren Listener – ohne Locks, ohne Engpässe.

Thread-lokale Puffer

Jeder HTTP-Worker-Thread hat seinen eigenen statischen Puffer für Request-Daten, Response-Daten und JSON-Parsing. Diese Puffer werden nie freigegeben und wiederverwendet – das eliminiert malloc/free im kritischen Request-Pfad vollständig.

Nebenläufigkeits-Budgets & Overload-Behandlung

Worker- und Verbindungszahlen sind begrenzt und Container-bewusst. Die effektive CPU-Anzahl ist das Minimum aus CPU-Affinität (taskset, cpuset) und cgroup-CPU-Quota (v1 und v2, z. B. ergibt docker run --cpus=1.5 2), nicht die Kernzahl des Hosts. Jedes Limit lässt sich per Umgebungsvariable überschreiben; ein ungültiger Wert bricht den Start ab. Die effektiven Werte stehen im Startup-Banner (Limits: ...) und werden zusammen mit Open/Peak/Rejected-Zählern auf /metrics ausgegeben.

Jede Einstellung kann auch in application.properties als tinox.limits.<name> stehen (z. B. tinox.limits.max_tasks=256); die Umgebungsvariable hat Vorrang. Die Dev-UI-API liefert die effektiven Werte und Live-Zähler unter /limits. HTTP/1 weist sofort ab (die epoll-Worker dürfen nicht blockieren); die Accept-Schleifen von HTTP/2, HTTP/3 und TLS sind bewusst einthreadig, ihr Backlog ist durch die Kernel-Listen-Queue begrenzt und sie erzeugen keine Threads. AMQP-Verbindungen nutzen spawn und zählen daher gegen TINOX_MAX_TASKS. Abgewiesene Anfragen werden nie automatisch wiederholt. Bind-Adresse: Standardmäßig binden alle Listener (HttpServer, @TinoxUIApp, WebSocket, HTTP/2, SSE) auf 0.0.0.0. TINOX_BIND_ADDRESS=127.0.0.1 beschränkt sie auf eine IPv4-Adresse (z. B. nur Loopback für lokale Dashboards); ein ungültiger Wert bricht den Start hart ab.

Benchmark: Tinox vs. Quarkus

Ein Sort-REST-Endpunkt wurde unter identischen Bedingungen gegen Quarkus (Java, native image) gemessen:

Testbedingungen: 5.000 Requests, Concurrency 20, Liste mit 20 Zahlen pro Request, Linux x86_64.

Vor- & Nachteile

Vergleich: Speichersicherheit

Tinox gibt dem Entwickler volle Kontrolle über den Speicher – wie C –, bietet aber keine statischen Garantien wie Rusts Borrow-Checker. Das bedeutet:

Einsatzgebiete

Weniger geeignet für…

• Frontend-Entwicklung (kein Browser-Target, kein WASM-Fokus)
• Datenwissenschaft / ML (kein NumPy-Äquivalent, keine Notebook-Integration)
• Mobile Apps (kein iOS/Android-Framework)
• Projekte, die ein riesiges Paket-Ökosystem benötigen (npm, Maven)

Vergleich mit anderen Sprachen

ORM & Lambda-Query-DSL

Tinox bietet ein typsicheres ORM nach dem JPA/QueryDSL-Prinzip. Klassen werden mit Annotations als Datenbank-Tabellen markiert. Abfragen laufen ausschließlich über ein Lambda-DSL — keine String-basierten Queries.

Annotations

Entity-Definition

@Entity
@Table("users")
class User {
    @Id @GeneratedValue
    var id: Int64
    @Column("name")
    var name: String
    @Column("age")
    var age: Int64
    @Column("active")
    var active: Bool
}

tinox.toml – [database]-Konfiguration

# PostgreSQL
[database]
driver = "postgres"
url    = "postgres://user:pass@localhost:5432/mydb"
pool   = 10

# MySQL / MariaDB
[database]
driver = "mysql"
url    = "mysql://user:pass@localhost:3306/mydb"

# SQLite (kein DB-Server nötig)
[database]
driver = "sqlite"
url    = "sqlite:///path/to/database.db"

Lambda-Query-DSL

// Alle Nutzer über 18, alphabetisch, max. 10 Ergebnisse
const adults: List<User> = DB::of(User)
    .filter(u -> u.age > 18)
    .orderBy(u -> u.name)
    .limit(10)
    .list()

// Einzelnen Nutzer lesen
const alice: User = DB::of(User)
    .filter(u -> u.name == "Alice")
    .first()

// Anzahl aktiver Nutzer
const n: Int64 = DB::of(User)
    .filter(u -> u.active == true)
    .count()

Lambda → SQL Übersetzungstabelle

Speichern, Ändern, Löschen

// INSERT (ID wird von der DB gesetzt)
const user: User = User {}
user.name = "Alice"
user.age  = 30
const saved: User = DB::of(User).save(user)

// DELETE
DB::of(User).delete(saved)

// Mehrere auf einmal speichern
const list: List<User> = List::new()
list.add(user1)
list.add(user2)
DB::of(User).saveAll(list)

Fehlerbehandlung

Datenbankfehler werden aktuell auf stderr protokolliert. Eine try/catch-Integration ist für eine spätere Version geplant. Verbindungsfehler beim Start beenden das Programm mit einer aussagekräftigen Fehlermeldung.