Migration von Hugo zu Zola

Tristan — Sun, 27 Sep 2026 00:00:00 +0000

Was passiert hier

Ich habe mich nach langer Überlegung dazu entschlossen meine Website von Hugo zu Zola umzuziehen.

Du fragst dich nun vielleicht, "Wer ist Hugo und was hat diese Zola mit ihm zu schaffen?" und, wenn du meinen Blog schon eine Weile verfolgst, wirst du dich vielleicht ebenfalls fragen, "Wo sind all die Artikel hin".

Auf diese Fragen möchte ich in diesem Artikel kurz eingehen.

Hugo und Zola

Static Site Generators (SSG)

Static Site Generators sind Programme, die aus Textdateien, oft Markdown, eine statische Webseite generieren.

Statische Seiten haben Vorteile gegenüber dynamischen bzw. server-seitig gebauten Seiten:

Laden extrem schnell
Sind sehr sicher (keine DB Zugriffe, kein JavaScript)
Einfach neuen Content zu schreiben und zu veröffentlichen
Kein spezieller Server zum Hosten benötigt

Hugo


Sprache	Go
Setup	Ausführbare Binärdatei
Konfiguration	YAML, TOML, JSON
Template Engine	Go Template
Community	Groß
Komplexität	Hoch
Lernkurve	Steil
Dokumentation	Sehr gut

Zola


Sprache	Rust
Setup	Ausführbare Binärdatei
Konfiguration	TOML
Template Engine	Tera
Community	Klein
Komplexität	Niedrig
Lernkurve	Flach
Dokumentation	Sehr gut

Warum das ganze

Ich finde Hugo nicht schlecht, im Gegenteil, es gab und gibt gute Gründe, warum ich mich ursprünglich dafür entschieden habe. Deshalb möchte ich hier auch keinen wertenden Vergleich anstellen, sondern nur die wenigen Punkte hervorheben, die mich veranlasst haben zu wechseln.

Was sind denn nun die Gründe für meinen Umzug?

Schlankere Themes: Die Zola Themes bestehen aus deutlich weniger Dateien und sind somit leichter anpassbar.
Tera: Ist eine mächtige, einfach zu erlernende Template Engine, die ich aus einem anderen Projekt bereits kenne.
Schlichtheit: Zola hat weniger Umfang, aber es macht genau das, was es soll und das mag ich an Werkzeugen.

Wann ist es fertig

Technischer Stand

Technisch ist die Seite bereits umgezogen, wenn du diesen Artikel hier liest. Meine CI/CD Pipeline für die Seite funktioniert und auch sonst bin ich mit dem Aufbau zufrieden.

Die Artikel

Wie bereits angesprochen, sind meine Artikel aktuell nicht sichtbar.

Das liegt erstens daran, dass ich die sogenannten "Frontmatter" anpassen muss, da diese nur bedingt kompatibel sind zwischen Hugo und Zola.
Zweitens habe ich mir bei der Umstellung alle Artikel nochmal durchgelesen und bin mit der Qualität nicht zufrieden.

Das bedeutet konkret, dass die Artikel nach und nach wieder online kommen werden. Alles in allem wird der Prozess vermutlich 1-2 Monate dauern.

Abschlussworte

Ich hoffe du schaust auch während der Umbauphase regelmäßig vorbei, es könnte sich lohnen, denn während ich die bestehenden Artikel einer Generalüberholung unterziehe, kommen auch neue Artikel dazu.

Rusty Bytes: Traits und mehr

Tristan — Wed, 11 Mar 2026 00:00:00 +0100

Was sind Traits?

Traits sind Rusts Version von Interfaces. Ein Trait definiert eine Schnittstelle, eine Menge von Methoden, die ein Typ implementieren muss, außer es gibt eine Standardimplementierung. Wer schon mit Interfaces aus C#, Java oder Kotlin gearbeitet hat, kennt das Konzept.

trait Greet {
    fn hello(&self) -> String;
}

struct German;
struct English;

impl Greet for German {
    fn hello(&self) -> String {
        String::from("Hallo!")
    }
}

impl Greet for English {
    fn hello(&self) -> String {
        String::from("Hello!")
    }
}

Traits können auch eine Standardimplementierung mitbringen, die ein Typ überschreiben kann aber nicht muss:

trait Greet {
    fn hello(&self) -> String {
        String::from("Hi!")
    }
}

So weit, so bekannt.

Interessant wird es, wenn man Traits als Parameter verwendet, denn da beginnt die eigentliche Frage: Was passiert dann zur Compile-Zeit und welche Auswirkungen hat es auf die Laufzeit?

Monomorphisierung – Polymorphismus zur Compile-Zeit

Wenn eine Funktion einen generischen Typ mit Trait-Bound erwartet, erzeugt der Rust-Compiler für jeden konkreten Typ, mit dem die Funktion aufgerufen wird, eine eigene spezialisierte Version. Das nennt sich Monomorphisierung.

fn greet<T: Greet>(g: &T) {
    println!("{}", g.hello());
}

Der Compiler sieht, dass greet mit German und English aufgerufen wird, und erzeugt intern je eine Funktion für Englisch und eine für Deutsch:

fn greet_german(g: &German) { println!("{}", g.hello()); }
fn greet_english(g: &English) { println!("{}", g.hello()); }

Das ist gleichbedeutend mit dem impl Trait-Syntax, der etwas lesbarer ist:

fn greet(g: &impl Greet) {
    println!("{}", g.hello());
}

Vorteil:
Zur Laufzeit gibt es keinen Overhead. Der Compiler kennt den konkreten Typ, kann ihn inline optimieren und direkt den richtigen Funktionsaufruf einsetzen.

Nachteil:
Die Binärgröße wächst, denn für jeden Typ, mit dem die Funktion genutzt wird, landet eine eigene Kopie im kompilierten Code.

Dynamic Dispatch – Polymorphismus zur Laufzeit

Manchmal ist der konkrete Typ erst zur Laufzeit bekannt, so zum Beispiel wenn verschiedene Typen in einer Liste gesammelt werden sollen.

Hier kommt dyn Trait ins Spiel.

fn greet(g: &dyn Greet) {
    println!("{}", g.hello());
}

Statt einer spezialisierten Funktion pro Typ erzeugt der Compiler ein Trait Object. Das ist ein sogenannter Fat Pointer, der aus zwei Teilen besteht, einem Zeiger auf die Daten und einem Zeiger auf eine vtable.

Die vtable wiederum ist eine Tabelle mit Funktionszeigern für alle Methoden des Traits, wo zur Laufzeit die richtige Implementierung nachgeschlagen und aufgerufen wird.

let greeters: Vec<Box<dyn Greet>> = vec![
    Box::new(German),
    Box::new(English),
];

for g in &greeters {
    println!("{}", g.hello());
}

Das wäre mit Monomorphisierung nicht möglich, da der Compiler den Typ jedes Eintrags zur Compile-Zeit kennen müsste.

Vorteil:
Flexibel, kleinere Binärgröße, heterogene Collections möglich.

Nachteil:
Laufzeit-Overhead durch den vtable-Lookup, keine Inlining-Optimierungen möglich.

Wann was?

	`impl Trait` / Generics	`dyn Trait`
Auflösung	Compile-Zeit	Laufzeit
Performance	Höher	Etwas geringer
Binärgröße	Wächst pro Typ	Konstant
Heterogene Collections	✗	✓
Typinformation	Vollständig bekannt	Zur Compile-Zeit nicht bekannt

Als Faustregel gilt:

impl Trait ist der Standard
dyn Trait kommt zum Einsatz wenn der Typ erst zur Laufzeit bekannt ist oder eine heterogene Collection benötigt wird.

Fazit

Traits sind mehr als nur Interfaces. Die Entscheidung zwischen Monomorphisierung und Dynamic Dispatch ist eine Entscheidung zwischen Compile-Zeit-Garantien und Laufzeit-Flexibilität.

Im Vergleich zu Java oder C#, wo jeder Methodenaufruf über eine virtuelle Tabelle aufgelöst wird, gibt Rust einem die Wahl und man muss sich explizit entscheiden, was man möchte.

Explizit und ohne Overhead, sind zwei Grundprinzipien bei Rust, die man sich mit einer etwas steileren Lernkurve und mehr Boilerplate-Code erkauft.

Devcartes - Rust