ZELYRA
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.
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.
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
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 |
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.
// 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 }
}
// 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 gemeinsame Deklaration kann Wiederholungen in unterstützten Abläufen verringern. Sie synchronisiert nicht automatisch jedes Datenbankschema, jede API, jedes Formular und jede Ansicht.
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.
// 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)
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
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.
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.
// 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")
}
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
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.
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.
// 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;
}
}
// 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.
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.
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.
// 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>
}
}
// 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
In Zelyra ist das Web keine externe Bibliotheks-Erweiterung, sondern ein nativer Sprachbestandteil: Routen, Validierung und HTML-Rendering verschmelzen zu einer homogenen Einheit.
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.
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.
Projektvorlagen und unterstützte Deklarationen helfen dir, einen datenbankgestützten Ablauf auszuprobieren. Erforderliche Schritte und Dateien hängen von Funktion und Deployment ab.
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.
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.
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.
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 →git clone https://github.com/sf1976/zelyra.git
cd zelyra && ./install.sh
zelyra run main.zyl