ZELYRA
ZELYRA / SPRACHVERGLEICH

Zelyra verstehen
im direkten Vergleich.

Vergleiche die dokumentierten Compiler-, Studio-, Web- und Datenbankabläufe von Zelyra mit etablierten Sprachen und Frameworks. Stabile Releases sind verfügbar; Unterstützung und Garantien hängen weiterhin von Funktion, Backend und geprüftem Ablauf ab.

Der architektonische Kern

Zelyra verbindet Sprachkonstrukte mit ausgewählten Datenbank- und Webabläufen. Compilerprüfungen decken umgesetzte Fälle ab; sie prüfen nicht automatisch jedes Modell, jede Abfrage, jedes Formular, jede Ansicht oder jedes Deployment.

1.2.41 Aktueller Quellstand Stabile Releases · aktive Entwicklung
CLI Compiler-Werkzeug Installationswege je Release
SQL Datenbankabläufe Prüfumfang in den Release-Dokumenten
T? Optionale Werte Compilergeprüftes Option<T>
1.3.0 Roadmap-Ziel MIR, Bytecode & Vertical Slice
Vergleichen mit:
Roadmap-Ankündigung · Version 1.3.0

Vorhaben auf dem Weg zu 1.3.0:
Compiler, Laufzeit und Projektstruktur.

Version 1.3.0 ist ein Roadmap-Meilenstein und noch kein veröffentlichtes Funktionspaket. Die Roadmap führt offene Arbeiten an Compiler- und Laufzeitparität, dem AST-/MIR-/Bytecode-Ausführungspfad und der Projektstruktur. Funktionen gelten erst nach Implementierung und bestandenen Prüfungen als abgeschlossen.

🏛️

1. Kanonische Vertical-Slice-Architektur

Das Standard-Projektlayout und Architekturprüfungen bilden eine Grundlage. Weitere Arbeiten an klaren Feature-Grenzen bleiben in der Roadmap; die aktuellen Prüfungen beweisen weder einen vollständigen Callgraphen noch jede Architektureigenschaft.

  • Umgesetzt: Standardlayout und begrenzte Deklarationsprüfungen
  • Aktuelle Grenze: Keine vollständige Callgraph- oder Effektanalyse
  • Umstellung: Nur-Lese-Layoutvorschau; mehrdeutige Dateien brauchen Prüfung
⚡

2. Multi-Tier: AST, MIR & Bytecode-VM

Der AST-Interpreter bleibt der Standard-Ausführungspfad. MIR und Bytecode sind für unterstützte Abläufe verfügbar; vollständige Web-/Laufzeitparität und weitere Release-Gates bleiben in der Roadmap.

  • Keine Leistungsbehauptung: Hier wird kein vergleichender Benchmark behauptet
  • Parität: Als unterstützt gelten nur tatsächlich geprüfte Abläufe
  • Diagnostik: Grenzen nach Backend und Ablauf werden dokumentiert
🛡️

3. Geprüfte Funktionen und klare Grenzen

Zelyra prüft konkrete deklarierte Typen, mandantengebundenes CRUD, Contracts und Datenbank-Constraints. Weitergehende Audit-Historie und Hauptbuchgarantien bleiben gesonderte Roadmap-Arbeiten; eine pauschale Korrektheitsgarantie wird nicht behauptet.

  • Mandantenscope: Für unterstützte generierte CRUD-/Datenbankpfade erzwungen
  • Live-UI: Es gibt keine veröffentlichte Sub-Millisekunden-Garantie
  • Auslieferung: CLI-Releases sind Einzelprogramme; Anwendungsbundles haben eigene Grenzen
01 / ÜBERSICHTSMATRIX

Die große Feature- und
Architektur-Matrix.

Ein ehrlicher und transparenter Überblick über fundamentale Architektureigenschaften von Zelyra im Vergleich zu etablierten Ökosystemen. Klicke oben auf eine Sprache, um Tabelle und Codebeispiele direkt zu fokussieren.

Merkmal / Disziplin Zelyra PHP (Laravel) TypeScript (Prisma) Rust (Axum) Go (net/http) Python (Django)
Single-Source Schema Sprachziel; Umfang je Funktion verschieden ✓ Nativ ✗ 3-4 Dateien ~ Generiert ✗ Macros ✗ Struct Tags ✗ Models+Forms
Nominale Fachtypen Compiler verhindert vertauschte IDs ~ Unterstützte Fälle ✗ Primitive int/str ✗ Nur strukturell ✓ Newtypes ~ Schwacher Alias ✗ Dynamisch
Prüfungen optionaler Werte Prüfumfang hängt von implementierten Fällen ab ~ Begrenzte statische Prüfungen ✗ Laufzeit TypeError ~ undefined/any ✓ Option<T> ✗ nil Panic ✗ NoneType Error
Compile-geprüftes SQL Unterstützte SQL-Fälle stehen im Handbuch ~ Unterstützte SQL-Fälle ✗ Laufzeit Strings ✗ ORM / DSL ✓ sqlx Macros ✗ Laufzeit Strings ✗ ORM / DSL
Integrierter Webserver Kein Apache, Nginx oder FPM zwingend ✓ Nativ in Rust ✗ PHP-FPM / Nginx ~ Node.js Engine ~ Crates nötig ✓ net/http ✗ Gunicorn / WSGI
Deployment-Artefakt CLI ist Single Binary; App-Bundle Ziel für v1.3.0 ✓ CLI 🛠️ Bundle (1.3.0) ✗ Source + Runtime ✗ Source + Node ✓ Single Binary ✓ Single Binary ✗ Source + Python
Abhängigkeiten-Footprint Abhängigkeiten je Installation und Betrieb ~ Je nach Deployment ~ Je nach Deployment ~ Je nach Deployment ~ Je nach Deployment ~ Je nach Deployment ~ Je nach Deployment
Leistungsdaten Kein vergleichender Benchmark veröffentlicht — — — — — —
RAM-Bedarf im Leerlauf Keine vergleichbare Messung veröffentlicht — — — — — —
Mandantensicherheit Unterstützte mandantengebundene Schema- und CRUD-Pfade ~ Unterstützte Pfade ~ Global Scope ✗ Manuell ✗ Manuell ✗ Manuell ~ Middleware
Ausführungsmodell AST-Referenz Standard; typisierte MIR & Bytecode im Rollout ✓ AST 🛠️ VM (1.3.0) ✗ PHP-FPM ~ Node JIT ✓ LLVM Native ✓ Native ✗ CPython (GIL)
Formale Verträge Vor-/Nachbedingungen (requires, ensures) im Typechecker ✓ Nativ (AST) ✗ Exceptions ✗ Keine ~ assert! Macros ✗ Keine ✗ Keine
02 / DATENMODELL & SCHEMA

Schema beschreiben.
Unterstützte Teile nutzen.

Eine Tabellendeklaration kann in ausgewählte Datenbank-, Typ-, Formular- und CRUD-Abläufe einfließen. Die konkrete Unterstützung hängt von Sprachkonstrukt und Backend ab.

customer.zyl ZELYRA
// Tabellendeklaration für unterstützte Folgeabläufe
table customers {
    id: Id primary auto
    name: String(100) required
    email: Email?
    active: Bool = true
}

// Unterstützte Formulardeklaration
form CustomerCreate -> customers {
    fields { name email }
}
Customer.php + migration.php LARAVEL
// 1. Migration, 2. Model, 3. FormRequest (3 Dateien synchron halten!)
class CreateCustomersTable extends Migration {
    public function up() {
        Schema::create('customers', function (Blueprint $t) {
            $t->id();
            $t->string('name', 100);
            $t->string('email')->nullable();
            $t->boolean('active')->default(true);
        });
    }
}
// In Customer.php: protected $fillable = ['name', 'email', 'active'];
// In StoreCustomerRequest.php: rules() => ['name' => 'required|max:100'...]
// 1. schema.prisma + npx prisma generate
model Customer {
  id     Int     @id @default(autoincrement())
  name   String  @db.VarChar(100)
  email  String?
  active Boolean @default(true)
}
// 2. Zod-Validierung muss manuell dupliziert werden:
export const CustomerSchema = z.object({
  name: z.string().min(1).max(100),
  email: z.string().email().optional(),
});
export type CustomerInput = z.infer<typeof CustomerSchema>;
// Diesel: migration.sql + schema.rs + models.rs
#[derive(Queryable, Selectable, Insertable, Serialize, Deserialize)]
#[diesel(table_name = crate::schema::customers)]
pub struct Customer {
    pub id: i32,
    pub name: String,
    pub email: Option<String>,
    pub active: bool,
}
// Validierungs-Crate validator muss zusätzlich implementiert werden:
#[derive(Validate, Deserialize)]
pub struct NewCustomer { ... }
💡
Eine Quelle kann doppelte Definitionen verringern

Eine gemeinsame Deklaration kann Wiederholungen in unterstützten Abläufen verringern. Sie synchronisiert nicht automatisch jedes Datenbankschema, jede API, jedes Formular und jede Ansicht.

03 / NOMINALE FACHTYPEN

Fachtypen machen
Unterschiede sichtbar.

Zelyra unterstützt benannte Fachtypen und prüft implementierte Typbeziehungen. Die genauen Regeln stehen im Handbuch; teste die Fälle, auf die dein Projekt angewiesen ist.

nominal_safety.zyl ZELYRA
// Nominale Typen: Strikte Trennung im Typensystem
type UserId = Id
type OrderId = Id

fn cancel_order(order: OrderId, user: UserId) {
    // ...
}

// ❌ COMPILE ERROR:
// TypeMismatch: Expected OrderId, but found UserId
cancel_order(current_user_id, current_order_id)
structural_bug.ts TYPESCRIPT
type UserId = string;
type OrderId = string;

// TypeScript verwendet rein strukturelle Typisierung!
function cancelOrder(order: OrderId, user: UserId) { ... }

// ⚠️ KEIN FEHLER: Kompiliert ohne jede Warnung!
// Führt zur Laufzeit zu stiller Datenbeschädigung:
cancelOrder(currentUserId, currentOrderId);
// PHP erlaubt nur primitive Skalare:
function cancelOrder(int $orderId, int $userId): void {
    // ...
}

// ⚠️ Vertauschte Parameter werden klaglos akzeptiert.
// Erst wenn der falsche Kunde oder Auftrag gelöscht wird,
// bemerkt man den Fehler in Produktion!
cancelOrder($currentUserId, $currentOrderId);
// In Rust geht das nur über das Newtype-Pattern:
#[derive(Debug, Clone, Copy, PartialEq, Eq, Serialize, Deserialize)]
pub struct UserId(pub u64);

#[derive(Debug, Clone, Copy, PartialEq, Eq, Serialize, Deserialize)]
pub struct OrderId(pub u64);

fn cancel_order(order: OrderId, user: UserId) { ... }
// Sicher, aber erfordert mühsames Entpacken order.0
🛡️
Warum das in der Unternehmenspraxis entscheidend ist

Manche Typsysteme behandeln Aliase desselben Grundtyps als austauschbar. Zelyra erprobt nominale Unterscheidungen; Compilerprüfungen gelten für unterstützte Typbeziehungen und verhindern nicht jeden Anwendungsfehler.

04 / NULL-SICHERHEIT

Optionale Werte sind sichtbar.
Die Prüfungen haben klare Grenzen.

Syntax für optionale Werte gehört zur Sprache. Statische Prüfungen decken unterstützte Zusammenhänge ab; sie garantieren nicht pauschal die Abwesenheit von Null- oder anderen Laufzeitfehlern.

safe_option.zyl ZELYRA
// T? ist Option<T>. Zugriff ohne Prüfung unmöglich:
user_name: String? = load_user_name(id)

// Compiler erzwingt vollständige Fallunterscheidung
match user_name {
    Some(name) => print("Willkommen, {name}!")
    None       => print("Gast-Benutzer")
}
null_danger.ts TYPESCRIPT
const userName = loadUserName(id);

// Optional Chaining täuscht Sicherheit vor:
const upper = userName?.toUpperCase();

// ⚠️ 'upper' ist jetzt undefined!
// Wandert ohne Compiler-Fehler in die SQL-Datenbank
// oder führt im Template zu 'Hello, undefined'
saveToDatabase({ name: upper });
$userName = loadUserName($id); // gibt ?string zurück

// Vergessenes if ($userName !== null) führt zum Fatal Crash:
echo strtoupper($userName);

// 💥 Fatal error: Uncaught TypeError:
// strtoupper(): Argument #1 ($string) must be of type string, null given
user, err := loadUser(id)
// Ein vergessenes err != nil oder nil-Pointer-Dereferenzierung:
println(user.Name)

// 💥 panic: runtime error: invalid memory address
// or nil pointer dereference
⚡
Option<T> statt trügerisches Optional Chaining

Optional Chaining ist eine praktische Schreibweise, ersetzt aber nicht die Behandlung fehlender Werte. Zelyra bildet optionale Werte als Option<T> ab; exhaustive Matches verlangen in unterstützten Fällen die Behandlung jeder Variante.

05 / DATENBANK-ABFRAGEN

Natives, compilergeprüftes SQL.
Abfragen bleiben sichtbar.

Zelyra prüft unterstützte SQL-Anweisungen gegen das deklarierte Schema und macht Abfragen ausdrücklich sichtbar. N+1-Abfragemuster werden dadurch nicht automatisch verhindert; prüfe und messe die tatsächlich ausgeführten Abfragen.

orders_query.zyl ZELYRA
// Direktes SQL: Compile-geprüft & null Overhead
fn get_top_customers(min_spend: Float) -> List<CustomerSummary> {
    sql {
        SELECT c.id, c.name, SUM(o.total) AS total_spent
        FROM customers c
        JOIN orders o ON o.customer_id = c.id
        WHERE c.active = true
        GROUP BY c.id, c.name
        HAVING SUM(o.total) >= :min_spend
        ORDER BY total_spent DESC;
    }
}
EloquentQuery.php LARAVEL
// Eloquent: Verschachtelter Query-Builder mit Reflection
$topCustomers = Customer::query()
    ->selectRaw('customers.id, customers.name, SUM(orders.total) as total_spent')
    ->join('orders', 'orders.customer_id', '=', 'customers.id')
    ->where('customers.active', true)
    ->groupBy('customers.id', 'customers.name')
    ->havingRaw('SUM(orders.total) >= ?', [$minSpend])
    ->orderByDesc('total_spent')
    ->get();
// ⚠️ selectRaw und havingRaw sind ungeprüfte Strings!
// Massiver Speicherverbrauch bei großen Hydrierungen.
// Prisma unterstützt komplexe GROUP BY / HAVING nur eingeschränkt:
const aggregations = await prisma.order.groupBy({
  by: ['customerId'],
  _sum: { total: true },
  having: { total: { _sum: { gte: minSpend } } },
});
// Benötigt anschließende zweite Query für Kundendaten:
// -> Gefahr von N+1 Latenz oder komplexen Raw-Queries!
// SQLx in Rust prüft SQL zur Compile-Zeit:
let customers = sqlx::query_as!(
    CustomerSummary,
    r#"SELECT c.id, c.name, SUM(o.total) as total_spent ... "#,
    min_spend
)
.fetch_all(&pool)
.await?;
// SQLx unterstützt vorbereitete Offline-Metadaten für Builds ohne Live-Datenbank.
📊
Kein ORM-Verschleierungsspiel

Zelyra bietet SQL-orientierte Datenbankabläufe für dokumentierte Fälle. Der Compiler prüft nicht jede Abfrage gegen eine Live-Datenbank; die Leistung hängt von Abfrage, Backend und Arbeitslast ab.

06 / WEBSERVER & ROUTING

Eine Web-Laufzeit.
Mit dokumentierten Grenzen.

Die Laufzeit bietet einen `serve`-Befehl und Seitenrouten für unterstützte Projektformate. Das Deployment hängt weiterhin von Anwendung, Host und Betriebsanforderungen ab.

profile_page.zyl ZELYRA
// Nativer Webserver läuft direkt via 'zelyra serve'
page "/users/{id}" {
    let user = find_user(id)?

    // Automatisches XSS-Escaping für alle Werte
    html {
        <h1>Profil: {user.name}</h1>
        <p>E-Mail: {user.email}</p>
    }
}
routes/web.php + Controller LARAVEL
// In routes/web.php:
Route::get('/users/{id}', [UserController::class, 'show']);

// In app/Http/Controllers/UserController.php:
public function show($id) {
    $user = User::findOrFail($id);
    return view('users.show', compact('user'));
}
// In resources/views/users/show.blade.php:
// <h1>Profil: {{ $user->name }}</h1>
// Erfordert Nginx + PHP-FPM Prozessmanagement im Betrieb!
// Next.js App Router:
export default async function UserPage({ params }: { params: { id: string } }) {
  const user = await db.user.findUnique({ where: { id: Number(params.id) } });
  if (!user) notFound();

  return (
    <div>
      <h1>Profil: {user.name}</h1>
      <p>E-Mail: {user.email}</p>
    </div>
  );
}
// Erfordert Node.js Runtime, JSX-Build-Pipeline und npm packages
async fn show_user(Path(id): Path<i32>) -> Response {
    let user = db::find(id).await;
    Html(format!("<h1>Profil: {}</h1>", user.name)).into_response()
}

let app = Router::new().route("/users/:id", get(show_user));
axum::serve(listener, app).await.unwrap();
// Benötigt Tokio Async-Runtime, Lifetimes und HTML-Escaping Crate
🚀
Von Grund auf für das Web konstruiert

In Zelyra ist das Web keine externe Bibliotheks-Erweiterung, sondern ein nativer Sprachbestandteil: Routen, Validierung und HTML-Rendering verschmelzen zu einer homogenen Einheit.

07 / PERFORMANCE & RESSOURCEN

Leistung & Ressourcen.
Messwerte stehen noch aus.

Für dieses Release liegen keine reproduzierbaren Benchmarks zu Startzeit, Speicherbedarf oder Image-Größe vor. Messwerte ergänzen wir, sobald ein wiederholbarer Testaufbau verfügbar ist.

08 / ENTSCHEIDUNGSHILFE

Wann wählst du was?
Ehrliche architektonische Leitplanken.

Keine Programmiersprache ist für jede erdenkliche Aufgabe die beste. Hier ist eine ehrliche Einschätzung, wann welches Werkzeug glänzt.

🐘 Bleib bei PHP / Laravel, wenn:

Du auf ein gewaltiges, jahrzehntelang gewachsenes Ökosystem und fertige Fertiglösungen angewiesen bist.

  • Du fertige Admin-Panels wie Filament oder Nova benötigst.
  • Du bestehende Monolithen mit eingespielten Teams weiterentwickelst.
  • Klassisches Webspace- oder Shared-Hosting zwingend vorgeschrieben ist.

🔷 Bleib bei TypeScript, wenn:

Du Code, Typen und Rendering nahtlos zwischen Browser und Backend teilen willst.

  • Du stark interaktive Frontend-Clients mit Next.js, Nuxt oder Svelte baust.
  • Du spezielle Node.js-APIs oder NPM-Visualisierungsbibliotheken nutzt.
  • Dein Team rein aus Frontend-Entwicklern besteht.

🦀 Wähle Rust, wenn:

Du Low-Level-Infrastruktur baust, bei der jedes Byte und Nanosekunden zählen.

  • Datenbank-Engines, Browser-Engines, Treiber oder Kryptografie.
  • Du absolute manuelle Kontrolle über Speicherlayouts und Threads benötigst.
  • Dein Projekt den Aufwand des Borrow-Checkers und langer Build-Zeiten rechtfertigt.

🐹 Wähle Go, wenn:

Du Cloud-Infrastruktur-Tools, Netzwerk-Proxies oder Kubernetes-Operatoren baust.

  • Reine I/O-Netzwerk-Gateways mit vielen parallelen TCP-Verbindungen.
  • Direkte Einbindung in das Kubernetes- und Docker-Ökosystem.
  • Du mit manuellem `if err != nil` und Boilerplate gut leben kannst.

⚡ Wähle Zelyra, wenn:

du eine Sprache mit integrierten Datenbank- und Webkonzepten erkunden möchtest.
Beginne mit einem kleinen Projekt und prüfe, ob die unterstützten Abläufe zu deinen Anforderungen passen. Kläre Datenbank-, Sicherheits- und Deployment-Grenzen, bevor du es für eine operative Anwendung auswählst.

🚀 Unterstützten Projektablauf ausprobieren

Projektvorlagen und unterstützte Deklarationen helfen dir, einen datenbankgestützten Ablauf auszuprobieren. Erforderliche Schritte und Dateien hängen von Funktion und Deployment ab.

🛠️ Lokaler Laufzeitbefehl

Die CLI enthält einen `serve`-Befehl für unterstützte Projektformate. Diese Seite macht keine Aussage zu Latenz oder Durchsatz; prüfe Lastverhalten und Deployment-Anforderungen selbst.

🧩 Perfekt für pragmatische CRUD- & Daten-Apps

Das Projekt verbindet relationale Daten und Webformulare in einer Werkzeugkette. Datenbankunterstützung und Abfrageprüfungen unterscheiden sich je Funktion und Backend; prüfe das erzeugte Verhalten und messe deine Arbeitslast.

🛡️ Sicherheit braucht Anwendungsprüfung

Leite Anwendungssicherheit nicht allein aus der Sprachsyntax ab: Prüfe erzeugte Ausgaben, validiere Eingaben, teste Berechtigungen und führe vor dem Deployment eine Sicherheitsprüfung durch.

Der 3-Schritte-Workflow: 1. Tabelle deklarieren ➔ 2. Formular & Route schreiben ➔ 3. zelyra serve ➔ ✓ Lokal ausprobieren

Editor & Tooling einrichten

Hole dir Syntax-Highlighting für .zyl-Dateien in VS Code, Sublime Text oder Neovim mit der offiziellen TextMate-Grammatik.

Schnellstart-Anleitung öffnen →
// Installationsbefehl
git clone https://github.com/sf1976/zelyra.git
cd zelyra && ./install.sh
zelyra run main.zyl