Rue, eine neue, kurz vor Weihnachten vorgestellte Programmiersprache, kombiniert Speichersicherheit mit guter Performance ohne Garbage Collector. Es handelt sich um eine Weiterentwicklung von Rust, die ein ähnliches Konzept verfolgt. Rue soll jedoch gerade für Einsteiger einfacher zugänglich sein. Eine Besonderheit ist, dass der KI-Assistent Claude den Compiler (x86-64 und ARM64) für Rue entwickelt.

Konzipiert wurde Rue von Steve Klabnik, der bei Ruby on Rails und Rust maßgeblich mitgewirkt hat. Er versucht, das speichersichere Borrowing-Konzept von Rust zu vereinfachen, das vielen Rust-Neulingen schwer zu verstehen fällt.

Rue verwendet affine Typen mit veränderbarer Wertesemantik. Das heißt, Entwicklerinnen und Entwickler können affine Typen nur einmal verwenden. Der Blog zeigt ein Beispiel:

struct FileHandle { fd: i32 }

fn example() {
    let handle = FileHandle { fd: 42 };
    use_handle(handle);     // handle moves here
    use_handle(handle);     // ERROR: value already moved
}

Kopieren ist jedoch möglich, wenn man es ausdrücklich deklariert:

@copy
struct Point { x: i32, y: i32 }

fn example() {
    let p = Point { x: 1, y: 2 };
    use_point(p);   // p is copied
    use_point(p);   // OK, p is still valid
}

Ein Wert, der konsumiert werden muss, lässt sich mit linear markieren:

linear struct DatabaseTransaction { conn_id: i32 }

fn example() {
    let tx = DatabaseTransaction { conn_id: 1 };
    // ERROR: linear value dropped without being consumed
}

Von Zig übernimmt Rue das Konzept von Ausdrücken, die bereits der Compiler auswertet, mit der Eigenschaft comptime. Auch Typen lassen sich so erzeugen:

fn Pair(comptime T: type) -> type {
    struct { first: T, second: T }
}

fn main() -> i32 {
    let IntPair = Pair(i32);
    let p: IntPair = IntPair { first: 20, second: 22 };
    p.first + p.second
}

Klabnik arbeitet für das Umsetzen seiner Ideen mit Claude. Er hatte zwar eine Vorstellung davon, wie Rue aussehen soll, ihm fehlte aber die Erfahrung im Bauen von Compilern. Diese Arbeit übernimmt die künstliche Intelligenz: „And you know what? It worked.“ Der erste Versuch, ein Programm zu kompilieren, funktionierte noch nicht, aber nach einer Debugging-Runde lief es dann.

Die Rue-Website betont, dass es sich um ein Forschungsprojekt in seinen Anfängen handelt, das nicht fertig für echte Projekte ist. Wer mitmachen möchte, findet bei GitHub Gelegenheit.

(who)

Die Monte-Carlo-Simulation hilft in der Produktentwicklung dabei, Prognosen realistischer zu machen. Nicht als harte Zusage, sondern als Blick auf Wahrscheinlichkeiten und damit auf das Risiko, das in komplexer Arbeit fast immer mitschwingt. Zeit also, sich tiefer damit auseinanderzusetzen, weshalb Dominique Winter in dieser Folge mit dem Flight Levels und Kanban Coach Felix Rink aus Köln spricht.

Fundierte Vorhersagen in der Produktentwicklung

Gemeinsam starten sie bei der Frage, wann etwas fertig ist und wie belastbar so eine Aussage eigentlich ist, wenn Teams in unsicheren Umfeldern arbeiten. Von dort geht es zur Idee hinter der Monte-Carlo-Simulation. Sie ist überraschend simpel. Vergangene Ergebnisse geben Hinweise darauf, wie sich Arbeit vermutlich auch künftig verteilen wird. Statt eine einzelne Zahl zu versprechen, entsteht eine Bandbreite. Fertigstellungen aus der Vergangenheit werden in vielen Durchläufen immer wieder neu kombiniert, bis ein Muster sichtbar wird. Manche Ergebnisse tauchen oft auf, andere sind selten.

Genau diese Verteilung ist in der Produktentwicklung hilfreich, weil Schwankungen zum Tagesgeschäft gehören. Schnell wird klar, dass es weniger um exakte Termine geht als um ein besseres Gefühl für Risiko. Die Simulation zeigt, mit welcher Wahrscheinlichkeit ein bestimmter Arbeitsumfang in einem bestimmten Zeitraum wirklich erreichbar ist. Das verändert, wie über Planung gesprochen wird. Zusagen werden zu bewussten Entscheidungen über Risiko und nicht zu Versprechen, die später unter Druck verteidigt werden müssen. Für Product Owner ist das besonders wertvoll, weil Gespräche mit Stakeholdern dadurch sachlicher werden und Erwartungen besser eingeordnet werden können.

Ein weiterer Schwerpunkt liegt auf den Daten. Entscheidend ist nicht, möglichst weit zurückzugehen, sondern eine Vergangenheit zu wählen, die der erwarteten Zukunft ähnelt. Kurze Zeiträume mit ausreichend vielen Datenpunkten liefern oft bessere Prognosen als lange Historien, in denen Sondereffekte alles verzerren. Auch eine feinere Betrachtung auf Tagesbasis kommt zur Sprache, weil sich Forecasts damit schneller aktualisieren lassen und Veränderungen im System früher auffallen.

Monte-Carlo-Simulation als laufendes Werkzeug

Spannend wird es dort, wo die Monte-Carlo-Simulation nicht als einmaliger Schritt verstanden wird, sondern als laufendes Werkzeug. Neue Erkenntnisse, zusätzliche Arbeit oder geänderte Rahmenbedingungen fließen direkt in den nächsten Forecast ein. So entsteht ein kontinuierlicher Abgleich zwischen Realität und Erwartung. Das unterstützt aktives Risikomanagement und hilft Teams, Prioritäten immer wieder neu auszurichten, ohne jedes Mal bei null anfangen zu müssen.

Am Ende geht der Blick über die klassische Fertigstellungsfrage hinaus. Überall dort, wo vergangenes Verhalten brauchbare Hinweise auf die Zukunft gibt, kann Monte Carlo helfen, Unsicherheit greifbar zu machen. In der Produktentwicklung ist das oft genau die Art von Pragmatismus, die fehlt. Nicht kompliziert, aber deutlich verlässlicher als Bauchgefühl.

Die aktuelle Ausgabe des Podcasts steht auch im Blog der Produktwerker bereit: „Forecasting mit der Monte-Carlo-Simulation“.

(mai)

Das Spring-Team hat die neue Major-Version Spring Shell 4.0.0 veröffentlicht. Sie ist auf dem zentralen Maven-Repository Maven Central verfügbar, soll einen signifikanten Meilenstein für die Spring Shell bedeuten und ist mit den aktuellen Spring-Framework- und Spring-Boot-Versionen kompatibel. Updates gibt es unter anderem für die Architektur, Null Safety und das Erstellen von Befehlen.

Modulare Architektur und JSpecify-Anbindung

Version 4.0 der Spring Shell basiert auf dem Spring Framework 7, das im November 2025 erschien. Das quelloffene Java-Framework brachte ein neues Konzept für Null Safety: Ebenso wie das Framework nutzt die Spring Shell nun das Open-Source-Projekt JSpecify für Null Safety, was Fehler durch den Umgang mit Null-Pointern verhindern soll.

Zudem bringt die neue Spring-Shell-Version ein überarbeitetes Befehlsmodell, um das Erstellen und Verwalten von Befehlen zu vereinfachen. Eine stärker modular aufgebaute Architektur soll der benutzerdefinierten Anpassung sowie Erweiterung der Shell zugutekommen. Die Dokumentation und Beispiele wurden ebenfalls aktualisiert, um insbesondere beim Einstieg in die Arbeit mit der Spring Shell zu helfen.

Migrationshinweise

Im Projekt-Wiki findet sich ein Migrationsguide. Dabei ist zu beachten, dass Anwendungen vor der Migration auf Spring Shell 4 zunächst auf die neueste 3.4.x-Version aktualisiert werden sollten.

Zu den Moduländerungen zählt, dass das spring-shell-core-Modul nicht länger auf Spring Boot und JLine angewiesen ist. Die Module spring-shell-standard und spring-shell-standard-commands wurden in das spring-shell-core-Modul integriert.

In Spring Shell 3 als deprecated (veraltet) markierte APIs und Annotationen sind entfallen, darunter Legacy-Annotationen wie ShellComponent und ShellMethod.

Shell-Anwendungen mit Spring Shell entwickeln

Mit der Spring Shell können Entwicklerinnen und Entwickler eine Spring-basierte Shell-Anwendung erstellen. Wie das Spring-Team ausführt, kann eine solche Kommandozeilenanwendung hilfreich sein, um mit der REST-API eines Projekts zu interagieren oder mit lokalen Dateninhalten zu arbeiten. Weitere Informationen – inklusive Beispielanwendungen und Tutorials – bietet das GitHub-Repository.

(mai)