ZELYRA
Understand Zelyra
through the languages you know.
Compare Zelyra’s documented compiler, Studio, web and database workflows with established languages and frameworks. Stable releases are available; support and guarantees still depend on the specific feature, backend and tested workflow.
Zelyra connects language constructs with selected database and web workflows. Compiler checks cover implemented cases; they do not automatically verify every model, query, form, view or deployment.
Work planned toward v1.3.0:
Compiler, runtime and project structure.
Version 1.3.0 is a roadmap milestone, not a released feature set. The roadmap tracks remaining work on compiler/runtime parity, the AST-to-MIR/Bytecode execution path, and project structure. Each capability will be called complete only after implementation and its stated checks pass.
1. Canonical Vertical Slice
The standard project layout and architecture checks already provide a foundation. Further work is tracked for clearer feature boundaries; the current checks do not prove a complete call graph or every architectural property.
- Implemented: Standard layout and bounded declaration checks
- Current limit: Not a complete call-graph or effect analysis
- Migration: Read-only layout preview; ambiguous files need review
2. AST, MIR & Bytecode VM
The AST interpreter remains the default execution path. MIR and Bytecode are available for supported execution workflows, while full web/runtime parity and remaining release gates are still tracked in the roadmap.
- No speed claim: No comparative benchmark is published here
- Parity: Only tested workflows are described as supported
- Diagnostics: Backend and workflow boundaries are documented
3. Documented checks and boundaries
Zelyra provides specific checks for declared types, tenant-scoped CRUD, contracts and database constraints. Broader audit-history and ledger guarantees remain separate roadmap work; no blanket correctness claim is made.
- Tenant scope: Enforced on supported generated CRUD/database paths
- Live UI: No sub-millisecond latency guarantee is published
- Distribution: CLI releases are single binaries; application bundling has separate limits
Direct Feature & Architecture
Comparison Matrix.
A transparent overview of fundamental capabilities across Zelyra, Laravel, TypeScript, Rust, Go, and Python. Click any language above to filter the matrix and code examples directly.
| Feature / Dimension | Zelyra | PHP (Laravel) | TypeScript (Prisma) | Rust (Axum) | Go (net/http) | Python (Django) |
|---|---|---|---|---|---|---|
| Single-Source Schema A language goal; coverage varies by feature | ✓ Native | ✗ 3-4 Files | ~ Generated | ✗ Macros | ✗ Struct Tags | ✗ Models+Forms |
| Nominal Domain Types Compiler forbids UserId = OrderId | ~ Supported cases | ✗ Primitive int/str | ✗ Structural only | ✓ Newtypes | ~ Weak alias | ✗ Dynamic |
| Optional-value checks Scope depends on implemented cases | ~ Limited static checks | ✗ Runtime TypeError | ~ undefined/any | ✓ Option<T> | ✗ nil Panic | ✗ NoneType Error |
| Verified SQL in Language See the handbook for supported SQL cases | ~ Supported SQL cases | ✗ Runtime strings | ✗ ORM / DSL | ✓ sqlx Macros | ✗ Runtime strings | ✗ ORM / DSL |
| Built-in Web Server No Apache, Nginx or FPM required | ✓ Native in Rust | ✗ PHP-FPM / Nginx | ~ Node.js Engine | ~ Crate needed | ✓ net/http | ✗ Gunicorn / WSGI |
| Deployment Artifact CLI is single binary; application bundle in v1.3.0 | ✓ CLI 🛠️ Bundle (1.3.0) | ✗ Source + Runtime | ✗ Source + Node | ✓ Single Binary | ✓ Single Binary | ✗ Source + Python |
| Dependency Overhead Dependencies vary by install and deployment | ~ Depends on deployment | ~ Depends on deployment | ~ Depends on deployment | ~ Depends on deployment | ~ Depends on deployment | ~ Depends on deployment |
| Performance data No comparative benchmark published | — | — | — | — | — | — |
| Idle RAM Consumption No comparable measurement published | — | — | — | — | — | — |
| Multi-Tenancy Isolation Supported scoped schema and generated CRUD paths | ~ Supported paths | ~ Global Scope | ✗ Manuell | ✗ Manuell | ✗ Manuell | ~ Middleware |
| Execution Pipeline AST reference standard; typed MIR & Bytecode in rollout | ✓ AST 🛠️ VM (1.3.0) | ✗ PHP-FPM | ~ Node JIT | ✓ LLVM Native | ✓ Native | ✗ CPython (GIL) |
| Design by Contract Pre-/post-conditions (requires, ensures) in typechecker | ✓ Native (AST) | ✗ Exceptions | ✗ Keine | ~ assert! Macros | ✗ Keine | ✗ Keine |
Describe a schema.
Reuse supported parts.
A table declaration can feed selected database, type, form and CRUD workflows. The exact integration depends on the construct and backend.
// 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 { ... }
A shared declaration can reduce repeated definitions in supported workflows. It does not keep every database schema, API, form and view automatically synchronized.
Domain types can make
data distinctions explicit.
Zelyra supports named domain types and checks implemented type relationships. Check the handbook for the exact rules and test the cases your project depends on.
// 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
Some type systems treat aliases of the same primitive as interchangeable. Zelyra experiments with nominal distinctions; compiler checks apply to supported type relationships and do not prevent every application bug.
Optional values are explicit.
Checks have a defined scope.
Optional-value syntax is part of the language. Static checks cover supported contexts; they are not a blanket guarantee against null-related or other runtime errors.
// 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 is useful syntax, but it does not replace handling an absent value. Zelyra represents optional values as Option<T>; exhaustive matches require handling each supported variant.
Native, compiler-checked SQL.
Queries stay explicit.
Zelyra checks supported SQL statements against the declared schema and keeps query behavior explicit. It does not automatically prevent N+1 query patterns; inspect and measure the queries your application issues.
// 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 supports prepared offline metadata for builds without a live database.
Zelyra exposes SQL-oriented database workflows for documented cases. The compiler does not validate every query against a live database, and performance depends on the query, backend and workload.
A web runtime.
With documented limits.
The runtime provides a `serve` command and page routes for supported project formats. Deployment still depends on the application, host and operational requirements.
// 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
Zelyra does not treat web protocols as third-party library bolt-ons. Routes, requests, and HTML responses are fundamental primitives of the language compiler.
Performance & resources.
Measurements pending.
No reproducible benchmark for startup time, memory use, or image size is published for this release. We will add measured data when a repeatable test setup is available.
When to choose what:
Honest architectural guidance.
No language is universally best for everything. Here is an honest appraisal of when each technology shines.
🐘 Stay with PHP / Laravel if:
You need a massive off-the-shelf ecosystem and immediate turnkey solutions.
- You heavily rely on packages like Filament Admin, Nova, Cashier, or Pulse.
- You maintain existing legacy codebases with deep Composer dependencies.
- Standard LAMP / Shared-Hosting deployment is a strict requirement.
🔷 Stay with TypeScript if:
You require complete code-sharing between complex browser clients and backend.
- You build heavy Single Page Apps (SPAs) with React, Next.js, or Vue.
- You use specialized npm packages with no native equivalent.
- Your team consists exclusively of JavaScript frontend engineers.
🦀 Choose Rust if:
You build low-level systems where manual memory layout and nanoseconds matter.
- Operating systems, game engines, database engines, or cryptography.
- You need zero-cost abstractions with custom manual allocator control.
- Your project can absorb the steep learning curve of lifetimes and borrow checking.
🐹 Choose Go if:
You build straightforward networking daemons or cloud-native tooling (Kubernetes/Docker).
- High concurrency with lightweight Goroutines for I/O proxies.
- Cloud orchestration and container tooling ecosystem.
- You are comfortable with repetitive `if err != nil` error handling.
⚡ Choose Zelyra if:
You want to explore a language with integrated database and web concepts.
Start with a small project and evaluate the supported workflows against your needs. Review the database, security and deployment limits before choosing it for an operational application.
Project templates and supported declarations can help you explore a database-backed workflow. The steps and files required depend on the feature and deployment.
The CLI includes a `serve` command for supported project formats. This page makes no latency or throughput claim; measure the workload and review deployment requirements yourself.
The project explores relational data and web forms in one toolchain. Database support and query checks vary by feature and backend; inspect the generated behavior and measure your workload.
Do not infer application security from language syntax alone: review generated output, validate inputs, test authorization, and perform a security review before deployment.
Ready to write Zelyra?
Get full syntax highlighting for .zyl files in VS Code, Sublime Text, or Neovim with the official TextMate Grammar.
View Setup Guide →git clone https://github.com/sf1976/zelyra.git
cd zelyra && ./install.sh
zelyra run main.zyl