Eine Sprache, die niemandem gehört

Rust, die Geschichte einer Programmiersprache und die Frage, wem unsere Werkzeuge eigentlich gehören

Über Programmiersprachen wird viel gestritten, meines Erachtens aber fast immer über die falschen Dinge. Geschwindigkeit, Syntax, ob geschweifte Klammern oder Einrückungshölle, ob der Compiler nörgelt oder schweigt. Das sind Fragen des Programmierer-Handwerks, und sie haben alle ihre Berechtigung. Sie verdecken aber eine andere, unbequemere Frage, die seltener gestellt wird: Wem gehört eigentlich das Werkzeug, mit dem wir bauen?

Eine Programmiersprache ist kein gesetztes Naturphänomen. Sie wird entworfen, finanziert, gepflegt aber auch gesteuert, und all das tut jemand, mit eigenen Interessen, in seinem ganz speziellen Kontext. Ein Compiler ist immer auch ein politisches Artefakt, auch wenn er sich als reine Technik tarnt. Wer das einmal verinnerlicht hat, kann die Liste der gängigen Sprachen mit anderen Augen betrachten. Und stellt fest, dass dort eine Auffälligkeit liegt.

Werkzeuge haben eine Herkunft

Man gehe die Liste der Sprachen durch, die heute die Basis moderner Software sind. C# ist von Microsoft, entstanden um die Jahrtausendwende, und niemand sollte sich von der späteren Quelloffenheit von .NET täuschen lassen: Die Sprache wurde als strategisches Gegenstück zu Java geboren, nachdem Microsoft damals seine eigene Java-Variante vor Gericht verloren hatte. Java selbst gehörte damals Sun und gehört heute Oracle, einem Konzern, der zur Programmiersprache vor allem dadurch unrühmlich in Erscheinung trat, dass er jahrelang darüber prozessierte, ob man eine Programmierschnittstelle überhaupt nachbauen darf. Go dagegen - eine ausgezeichnete Sprache, kommt von Google, entworfen jedoch vordergründig für Googles eigene Infrastrukturherausforderungen. Swift kommt von Apple und existiert, damit Entwickler sich auf Apples Plattformen behaglicher einrichten und seltener auf die Idee kommen, sie zu verlassen, die Reinform des freundlichen Lock-Ins.

Das ist kein Skandal. Konzerne bauen Werkzeuge, die ihren Zwecken dienen, und manche dieser Werkzeuge sind hervorragend. Aber es ist eine Tatsache mit Konsequenzen. Wer eine Sprache wählt, wählt einen Eigentümer mit. Er wählt einen Strategiehorizont, einen Support-Lebenszyklus, eine Lizenzpolitik und eine Roadmap, deren Prioritäten woanders gesetzt werden. Man baut sein Haus auf einem Grundstück, das jemand anderem gehört, und der Pachtvertrag ist hier nie verhandelbar.

Rust fällt aus dieser Reihe. Nicht, weil es makellos wäre, dazu kommen wir noch, sondern weil seine Herkunft eine andere Geschichte erzählt.

Ein Nebenprodukt, kein Strategieprojekt

Rust begann nicht im Strategiepapier eines Konzerns, sondern als persönliches Projekt eines einzelnen Entwicklers. Graydon Hoare arbeitete Mitte der 2000er Jahre an einer Sprache, die das auf damals schon Jahrzehnte alte Problem lösen sollte, dass systemnahe Software entweder schnell oder sicher ist, aber selten wirklich beides. Der Name, so will es die Legende, geht auf Rostpilze zurück, eine Gruppe von Organismen, die für ihre Robustheit und ihre redundanten Lebenszyklen bekannt sind. Schon die Namensgebung war eher Biologie als marketing-gesteuertes Branding.

Mozilla nahm sich des Projekts ab 2009 an, weil die Stiftung ein ganz konkretes Problem hatte: einen Browser, dessen Engine in C++ geschrieben war und dessen Sicherheitslücken sich zu großen Teilen auf genau die sprachinhärenten Speicherfehler zurückführen ließen, die Hoares Sprache wiederum verhindern wollte. Aus dieser Verbindung entstand das Browser-Engine-Projekt Servo, ein Versuchsfeld, auf dem Rust erwachsen wurde.

Und es wurde langsam, Schritt für Schritt, erwachsen. Zwischen den ersten öffentlichen Versionen und dem stabilen Release 1.0 im Mai 2015 lagen Jahre, in denen sich die Sprache bis zur Unkenntlichkeit veränderte. Besonders aufschlussreich ist, was in dieser Zeit verschwand. Frühe Rust-Versionen hatten eine Laufzeitumgebung, leichtgewichtige Threads nach dem Vorbild von Go, sogar Ansätze von automatischer Speicherbereinigung. All das wurde wieder herausoperiert. Rust hat seinen eigenen Unterbau abgeschafft, bewusst und mühsam, weil das Projekt zu der Überzeugung kam, dass eine Sprache ohne erzwungene Laufzeit grundsätzlich freier ist. Dieser Schritt ist kein Detail der Versionsgeschichte. Er ist der Kern der Sache.

Der Pakt mit der Laufzeit

Hier lohnt es sich, den Vergleich zu C# und Java sauber zu ziehen, denn an dieser Stelle entscheidet sich, warum Rust überhaupt eine Souveränitätsfrage ist.

Sicheres Programmieren bedeutet im Wesentlichen, eine Klasse von Fehlern zu verhindern: Zugriffe auf Speicher, der nicht mehr oder noch nicht gültig ist. Diese Fehler sind nicht harmlos. Sie sind seit Jahrzehnten die ergiebigste Quelle ernsthafter Sicherheitslücken überhaupt, das sind genau die Lücken, über die wir jeden Tag lesen. Microsoft hat öffentlich gemacht, dass rund siebzig Prozent der von ihm vergebenen Schwachstellenkennungen auf Speicherfehler zurückgehen. Bei Chrome und Android sieht die Größenordnung nicht anders aus.

C# und Java lösen dieses Problem, indem sie eine Laufzeitumgebung zwischen das Programm und die Maschine schieben. Die CLR bei .NET, die JVM bei Java. Diese Runtime verwaltet den Speicher, räumt auf, prüft Zugriffe und fängt vieles ab, was sonst zur Katastrophe würde. Der Preis dafür ist eine dauerhafte Abhängigkeit. Das fertige Programm läuft nicht für sich allein. Es braucht diese Runtime, um überhaupt zu starten, und diese Runtime ist ein gepflegtes Produkt mit einem Eigentümer, einem Versionsschema und einem Support-Ende. Die Runtime ist ein Engpass, an dem ein Konzern sitzt, zwischen den Anwendern (uns) und seiner (unserer) eigenen Hardware.

Rust lehnt diesen Pakt ab. Die Speichersicherheit wird nicht zur Laufzeit von einer separaten Aufsichtsinstanz durchgesetzt, sondern vom Compiler, bevor das Programm überhaupt existiert. Das berüchtigte Konzept von Eigentümerschaft und Ausleihe, der Borrow-Checker, ist im Grunde genau das: ein Prüfsystem, das zur Übersetzungszeit beweist, dass das Programm keine ungültigen Speicherzugriffe enthält. Wenn der Compiler zufrieden ist, fällt die Aufsicht ersatzlos weg. Das Ergebnis ist ein natives Binary, das nichts voraussetzt. Keine geschlossene proprietäre Runtime, keine virtuelle Umgebung, keinen Interpreter. Eine Datei, die man ausführt, dann archiviert, in zehn Jahren wieder hervorholt, und sie läuft, weil sie von niemandem abhängt, der in der Zwischenzeit den Support eingestellt haben könnte.

Das ist die technische Substanz der gesamten Souveränitätsfrage. Es geht nicht darum, dass Rust schneller ist als C# (was es oft ist) oder eine elegantere Syntax (was es oft hat) hätte. Es geht darum, dass Rust die Sicherheit liefert, für die man bei den verwalteten Sprachen mit einer dauerhaften Abhängigkeit bezahlt, und dafür keine Abhängigkeit verlangt. Sicherheit ohne unkalkulierbaren Vermieter.

Wem gehört die Sprache

Bleibt die Frage der Steuerung. Eine Sprache ohne erzwungene Runtime ist schon viel wert, aber sie wäre wenig wert, wenn ihre Weiterentwicklung in der Hand eines einzelnen Konzerns läge.

Hier wurde Rust ausgerechnet von einer wirtschaftlichen Krise gerettet. Als Mozilla im August 2020 in großem Stil Personal entlassen musste, traf es auch das Servo- und das Rust-Team hart. Ein Projekt, das so eng an einen einzigen Träger gebunden ist, kann an so einem Punkt sterben oder von einem größeren Akteur geschluckt werden. Stattdessen wurde Anfang 2021 die Rust Foundation gegründet, eine eigenständige Stiftung, in der mehrere Konzerne als zahlende Mitglieder sitzen, aber keiner allein das Sagen hat. Die Sprache wird über einen öffentlichen RFC-Prozess weiterentwickelt, die Werkzeugkette ist vollständig quelloffen, und die Paketregistrierung crates.io verlangt weder Lizenzgebühren noch Anmeldung bei einem Cloud-Plattformbetreiber.

Man sollte an dieser Stelle der Versuchung widerstehen, in die üblichen bekannten Hochglanz-PPTs zu verfallen. Die Rust Foundation ist mit Sicherheit kein Idyll. Die zahlenden Konzerne nehmen natürlich Einfluss, schon weil sie die Gehälter vieler Mitwirkender mittelbar finanzieren. Die Geschichte des Projekts kennt handfeste Governance-Konflikte. Ende 2021 trat das gesamte Moderationsteam geschlossen zurück, mit der Begründung, es könne das damalige Kernteam nicht zur Rechenschaft ziehen. Zwei Jahre später löste ein Entwurf für eine restriktive Markenrichtlinie erheblichen Unmut in der Gemeinschaft aus, weil er den Gebrauch des Namens und des Logos enger fassen wollte, als vielen lieb war. Wenn wir offen über Rust reden, lässt das nicht wegdiskutieren. Eine vendorneutrale Sprache ist kein Zustand, sondern ein dauerhaft zu erkämpfendes Gleichgewicht.

Aber selbst mit diesen Einschränkungen bleibt der Befund deutlich. Rust ist eine der wenigen Sprachen mit ernsthafter industrieller Verbreitung, die keinem Hyperscaler gehört. Das ist die strukturelle Eigenschaft, auf die es ankommt.

Die Ironie der Sponsoren

Und nun zur unbequemsten Stelle, die zugleich die interessanteste ist. Wer in der Rust Foundation finanziell mitspielt, das sind unter anderem Amazon, Google, Microsoft und Meta. Microsoft schreibt sicherheitskritische Komponenten von Windows in Rust neu. Google hat Rust nach Android gebracht und in den Linux-Kernel hineinverhandelt. Dieselben Konzerne also, gegen deren Datensammel- und Lock-In-Logik sich der ganze Souveränitätsgedanke richtet, sind Rusts größte Geldgeber.

Das sieht nach einem Widerspruch aus, und man könnte diesen Essay an dieser Stelle peinlich berührt abbrechen. Tatsächlich ist es der Punkt, an dem die Sache erst richtig spannend wird.

Warum tun die das? Mit Sicherheit nicht aus Idealismus. Speicherfehler kosten diese Konzerne jedes Jahr enorme Summen, in Form von Sicherheitslücken, Notfall-Patches, Vertrauensschäden und Personal, das nichts anderes tut, als uralte C- und C++-Codebasen zu flicken. Rust senkt diese Kosten messbar. Die Konzerne investieren in Rust aus reinem Eigeninteresse, so wie sie in alles aus Eigeninteresse investieren.

Der entscheidende Punkt ist, was aus diesem Eigeninteresse geworden ist. Weil Rust quelloffen ist, weil die Steuerung in einer vendorneutralen Stiftung liegt und weil das Ergebnis ein natives Binary ohne herstellergebundene Runtime ist, lässt sich diese Sprache nicht einhegen. Die Konzerne können sie verbessern, sie können sie verbreiten, sie können sie für ihre Zwecke einspannen. Aber sie können sie nicht zumachen. Sie haben ein Werkzeug mitfinanziert, das sie nicht besitzen. Das jederzeit geforkt werden kann.

Der Punkt wird schärfer, wenn man ihn an einem Gegenbeispiel prüft. Microsoft kann Rust nicht zumachen. Eine andere tragende Säule der Entwicklerwelt hat derselbe Konzern dagegen sehr wohl vereinnahmt: GitHub, einst das Symbol für Offenheit und Neutralität, wurde nach dem Kauf 2018 Schritt für Schritt zum Werkzeug der eigenen KI- und Plattformstrategie umgebaut, mitsamt der dabei gebrochenen Versprechen. Diese Chronologie eines Wortbruchs habe ich an anderer Stelle ausführlich nachgezeichnet. Der Unterschied zu Rust liegt allein in der Struktur. GitHub war ein Unternehmen mit einem Eigentümer und damit kaufbar. Rust ist eine Sprache mit einer vendorneutralen Stiftung und einem quelloffenen Unterbau und damit nicht einverleibbar. Es ist dieselbe Konzernlogik. Bei einem Unternehmen greift sie, bei einer Sprache, die niemandem gehört, läuft sie ins Leere.

Für den Einzelnen, für die kleinen Developer, für den Homelab-Betreiber, der seine eigene Infrastruktur jenseits der großen Plattformen aufbaut, ist das ein bemerkenswertes Geschenk. Aber es wäre ein Missverständnis, die Sache auf das Schrauberzimmer zu verengen. Dieselbe Eigenschaft, die dem Homelab nützt, nützt dem mittelständischen Maschinenbauer, der nicht möchte, dass sein Steuerungscode am Support-Lebenszyklus eines fremden Konzerns hängt. Sie nützt der Behörde, der Klinik, dem Energieversorger, kurz jeder Organisation, deren Software über Jahrzehnte laufen muss und deren Betreiber nicht jedes Mal zittern will, wenn ein Hersteller in Übersee seine Roadmap ändert. Und sie nützt, auf einer ganz anderen abstrakten Ebene, unseren ganzen europäischen Volkswirtschaften, die gerade mühsam begreifen, wie tief ihre Verwaltung, ihre Kliniken und ihre kritische Infrastruktur von einer Handvoll ausländischer Anbieter abhängen. Das Homelab ist nur die kleinste und sichtbarste Ausführung einer Frage, die sich bis hinauf zur staatlichen Ebene stellt.

Eine produktionsreife Systemsprache, deren Entwicklung von den Sicherheitsbudgets der Hyperscaler bezahlt wurde, deren Kontrolle aber nicht bei ihnen gelandet ist. Was für ein schöner Gedanke. Souveränität als Nebenwirkung fremder Big-Tech-Kostenrechnung. Das ist kein moralischer Sieg über BigTech, sondern etwas Nüchterneres und Verlässlicheres, ein struktureller Umstand, der unabhängig davon gilt, ob die Konzerne morgen ihre Meinung ändern.

Wenn Staaten Speichersicherheit zur Infrastruktur erklären

Wie ernst die Lage inzwischen genommen wird, zeigt ein Blick auf die staatliche Seite. Anfang 2024 veröffentlichte das technische Beratungsbüro des Weißen Hauses ein Papier, das ungewöhnlich direkt wurde: Es benannte speichersichere Programmiersprachen als Weg zu belastbarer Software und zeigte umgekehrt mit dem Finger auf C und C++ als Quelle systemischer Risiken. Die zuständige US-Cybersicherheitsbehörde fährt seither eine Linie, die Speichersicherheit nicht mehr als reine Kür, sondern als Basis-Grundanforderung behandelt.

Man muss diese Initiativen nicht für die Stimme der Vernunft halten, und ein gesunder Reflex gegenüber staatlichen Empfehlungen schadet selten. Es liegt sogar eine eigene Ironie darin, dass ausgerechnet die Regierung jenes Landes zur Umkehr mahnt, dessen Konzerne die heutige Abhängigkeit überhaupt erst geschaffen haben. Und es ist nicht beim einsamen Ruf aus Washington geblieben. Schon ein Jahr zuvor hatten die US-Sicherheitsbehörden gemeinsam mit ihren Partnern aus Großbritannien, Kanada, Australien und Neuseeland einen Leitfaden vorgelegt, der Softwarehersteller auffordert, sich verbindliche Fahrpläne hin zu speichersicheren Sprachen zu geben. Wenn ein halbes Dutzend Regierungen aus aller Herren Kontinente anfängt, die Wahl der Programmiersprache als Frage kritischer Infrastruktur zu behandeln, dann ist die Diskussion endgültig aus der Nische des reinen Programmier-Handwerks heraus. Es geht nicht mehr um reinen Geschmack. Es geht um die Frage, auf welchem Fundament eine Gesellschaft ihre Software baut, und wer dieses Fundament kontrolliert. Oder eben nicht.

Souveränität im Konkreten

Was bedeutet das alles, heruntergebrochen auf eine einzelne Entscheidung? Was ändert sich konkret, wenn jemand seine eigenen Werkzeuge, sein Homelab-Tooling, seine kleinen Helfer in Rust schreibt statt in Python, Go oder C#, wie es Canonical in Ubuntu gerade tut.

Es ändert sich, dass unter dem fertigen Programm keine Laufzeit liegt, die ein Konzern für veraltet erklären kann. Es ändert sich, dass kein Plattformbetreiber mit seinem Support-Lebenszyklus eine Uhr stellt, die man selbst nicht gestellt hat. Wenn Microsoft das Support-Ende einer .NET-Version verkündet, dann tickt unter der eigenen Software ein Countdown, dessen Startzeitpunkt jemand anderes festgelegt hat. Fremdgesteuerte Obsoleszenz. Rust gibt diese Uhr zurück in die eigene Hand. Das Binary, das heute kompiliert wurde, lässt sich archivieren und in vielen Jahren unverändert ausführen. Die gesamte Werkzeugkette, vom Compiler über den Paketmanager bis zur Möglichkeit, einen eigenen Spiegel der Paketregistrierung zu betreiben, lässt sich vollständig selbst hosten. Es gibt keine Stelle in dieser Kette, an der zwingend ein fremder Dienst erreichbar sein muss.

Das ist die praktische Übersetzung des Souveränitätsgedankens. Unabhängigkeit von der Hyperscaler-Logik ist erreichbar, das ist die wiederkehrende These hinter jedem ernstgemeinten Homelab, bei jedem besseren Hoster, und im Kern dieselbe Einsicht, die der auf dem 39C3 ausgerufene Digital Independence Day auf einen Satz bringt: digitale Abhängigkeit ist kein Naturgesetz, sondern eine aktive Entscheidung. Diese Entscheidung habe ich für mein eigenes Postfach längst getroffen, und sie endet nicht an der Mailadresse. Die Wahl der Programmiersprache ist eine der tragenden Entscheidungen in diesem Gebäude, keine bloße Geschmacksfrage am Rand.

Reboot nach drei Jahrzehnten

Ich sollte an dieser Stelle offenlegen, dass dieser Essay nicht von einer neutralen Werkbank aus geschrieben ist. Ich habe mit genau diesen Werkzeugen eine Geschichte, und sie reicht weit zurück. Meine ersten Schritte machte ich mit Watcom C++, damals der schwergewichtige DOS-Compiler, mit dem man sich damals Respekt erarbeitete. Geliebt habe ich aber etwas anderes: Borland C++ mit Turbo Vision, diese textbasierte Oberfläche in ihrem unverwechselbaren Blau, in der sich Dialoge und Menüs anfühlten wie eine kleine, vollständig begreifbare Welt. Danach kam Delphi, Object Pascal in einer Umgebung, die das Programmieren beinahe mühelos erscheinen ließ.

Visual Basic habe ich in diesen Jahren mit einer Arroganz betrachtet, für die ich mich heute aber auch nur halbherzig schäme. Und VBA halte ich nach wie vor für eine der schlimmsten Verirrungen, die die Softwaregeschichte hervorgebracht hat. C# habe ich seit den Delphi-Tagen mehrfach in die Hand genommen, und ich bin nie damit warm geworden. Das Bemerkenswerte daran erschließt sich erst mit etwas Abstand. Delphi und C# tragen die Handschrift desselben Mannes. Anders Hejlsberg war der Architekt hinter Turbo Pascal und Delphi, dann wechselte er zu Microsoft und wurde zum Chefarchitekten von C#. Das Werkzeug, das ich liebte, und das Werkzeug, mit dem ich nie warm wurde, stammen also vom selben Kopf. Klingt paradox. Was sich geändert hatte, war nicht die Entwurfshand. Es war alles drumherum: der Eigentümer, die Laufzeit, das Ökosystem, in das die Sprache eingelassen war. Genau das ist im Kleinen die These dieses ganzen Essays. Nicht die Sprache war das Problem. Es war der Vermieter.

Ich habe, das muss ich ehrlich sagen, nie professionell programmiert. Niemand hat mich je dafür bezahlt, mich um diese Dinge zu kümmern, und vielleicht ist gerade das der Punkt: Es ging immer um das Handwerk und die Neugier, nie um meine Gehaltsabrechnung. Nach drei Jahrzehnten des gelegentlichen Anfassens und Wiederweglegens fange ich jetzt richtig an, als blutiger Anfänger, mit allem, was das an Mühe bedeutet. Ein Reboot, und zwar mit Rust. Dass es Rust geworden ist und nicht die Sprache, zu der mich meine eigene Werkzeuggeschichte eigentlich hätte führen müssen, ist kein Zufall.

Es ist dieselbe Entscheidung, die dieser ganze Essay umkreist. Diesmal nicht beschrieben, sondern aktiv getroffen.

Das beste Werkzeug für den Job

"Das beste Werkzeug für den Job", das ist der Satz, mit dem in dieser Branche jede unbequeme Frage beerdigt wird. Er klingt nach nüchternem Pragmatismus, nach Erwachsensein, nach der Absage an jede Ideologie. Wer ihn ausspricht, steht scheinbar über den Dingen, während sich alle anderen in Glaubenskriegen verlieren. Genau darin liegt sein Trick.

Denn "das beste" ist nie eine rein technische Größe. Was als bestes Werkzeug gilt, hängt vollständig davon ab, welche Kriterien man überhaupt zur Bewertung zulässt. Wer nur Benchmarks, Feature-Listen und Einarbeitungszeit zählt, hat bereits eine Entscheidung getroffen, ohne sie auszusprechen: dass es egal sei, wem das Werkzeug gehört, wovon es abhängt und was es mit der eigenen Unabhängigkeit macht. Dieses Weglassen essentieller Fakten ist selbst eine Wertung, im besten Fall ein Selbstbetrug. Die vermeintlich unpolitischste Werkzeugwahl ist in Wahrheit die, die ihre Politik am gründlichsten versteckt.

Ich plädiere sicherlich nicht dafür, die technische Eignung zu ignorieren. Ein Werkzeug, das die Aufgabe nicht erfüllt, nützt auch der reinsten Gesinnung nichts. Ich plädiere dafür, die zweite Frage gleichberechtigt neben die erste zu stellen. Nicht nur, ob ein Werkzeug die Arbeit erledigt, sondern auch, wem ich mich damit ausliefere. Beides gehört in dieselbe Rechnung, mit demselben Gewicht. Wer die zweite Frage als ideologischen Ballast abtut, hat die erste längst zur einzig erlaubten erklärt, und das ist die ideologischste Haltung von allen.

Kein Freibrief

Damit der Essay nicht in die Falle tappt, die er anderen vorwirft, gehört ein offener und kritischer Schluss dazu.

Rust ist eine Sprache, kein moralischer Standpunkt. Ein Werkzeug macht niemanden souverän, indem man es bloß in die Hand nimmt. Ein in Rust geschriebenes Programm, das brav seine Daten an eine fremde SaaS-Schnittstelle sendet, ist genau so abhängig wie jedes andere. Die Sprache liefert die strukturelle Möglichkeit von Unabhängigkeit, nicht die Unabhängigkeit selbst. Letztere bleibt und erfordert eine aktiv gelebte Praxis, kein Häkchen auf einer Liste.

Es gehört auch dazu, dass Rust seine Zumutungen hat. Der Borrow-Checker, der die ganze Souveränitätsgeschichte technisch überhaupt erst trägt, ist für Einsteiger ein notorisch unangenehmer Gesprächspartner. Schwierig. Er lehnt Code ab, der in anderen Sprachen längst liefe, und er erklärt seine Gründe in einer Tonlage zwischen pedantischem Besserwisser und herablassenden Arroganzling. Das ist der Preis der Konstruktion, und man sollte ihn kennen, bevor man ihn bezahlt. Hinzu kommt eine Fragilität, die nichts mit der Sprache selbst zu tun hat, aber mit ihrem Ökosystem: Eine Handvoll grundlegender Pakete, auf denen halb crates.io aufbaut, wird von sehr wenigen Menschen gepflegt, oft unbezahlt. Auch das ist eine Abhängigkeit, nur eine andere als die von einem Konzern.

Trotzdem bleibt der Befund stehen. Von den Sprachen, die heute ernsthaft zur Wahl stehen, ist Rust diejenige, deren Architektur und deren Steuerung am wenigsten verlangen, dass man jemand anderem vertraut. Sie gehört keinem Hyperscaler, sie schiebt keine fremde Laufzeit zwischen das Programm und eure Maschine, und ihre Geschichte ist die eines Nebenprodukts, das sich nie wieder einfangen ließ. Eine Sprache, die niemandem gehört, ist kein Garant für Souveränität.

Aber sie ist eine Sprache, mit der man sich Souveränität nehmen kann. Ohne Erlaubnis.

Dieser Essay gehört in eine Reihe von Texten zur digitalen Souveränität. Die Kommunikationsebene behandelt der Beitrag zum di.day und zum Wechsel auf mailbox.org, die Datenebene der Umzug von Nextcloud zu OpenCloud. Die Plattformebene, GitHub gegen GitLab, ist im Text oben bereits verlinkt. Rust ist in diesem Bild die Sprachebene, das Fundament unter allem anderen.