Rust hat sich in den letzten Jahren als eine der beliebtesten Programmiersprachen für Systemprogrammierung etabliert, nicht zuletzt wegen seiner Sicherheit, Performance und modernen Toolchain. Gleichzeitig gewinnt WebAssembly (Wasm) stetig an Bedeutung als Zielplattform, die Webanwendungen und serverseitige Anwendungen beschleunigt und portabel macht. Die Kombination aus Rust und WebAssembly verspricht also viel – aber welchen Weg sollte man gehen, wenn man nicht einfach nur fertige Lösungen und Frameworks nutzen, sondern verstehen will, was unter der Haube passiert? Die üblichen Empfehlungen greifen auf Werkzeuge wie wasm-bindgen zurück, die den Kompilierungsprozess scheinbar magisch vereinfachen. Doch es gibt einen alternativen, bewussten Weg, Rust in WebAssembly zu übersetzen, und dieser „harte Weg“ lohnt sich, um tiefere Einblicke in die WebAssembly-Architektur und Rusts Kompilierung zu gewinnen.
Ideal ist dabei, den Umgang mit Exporten, Importen, Speicherverwaltung und Optimierungen wie Link-Time-Optimization (LTO) zu meistern. Im Folgenden beleuchten wir die wichtigsten Schritte und Herausforderungen auf diesem Weg und liefern zugleich Tipps, wie man schlanke, effiziente WebAssembly-Module aus Rust-Code gewinnt. Rust zu WebAssembly – Die Grundlagen Zunächst gilt es zu verstehen, wie Rust überhaupt WebAssembly-Code erzeugt. Hierfür bietet Rust offiziell den Target-Wert wasm32-unknown-unknown an, der WebAssembly ohne weitere Plattform-Schnittstellen beschreibt. Um eine Rust-Bibliothek für Wasm zu erstellen, empfiehlt sich das Erzeugen eines neuen Projekts als Bibliothek, also mit cargo init --lib. Wichtig ist dabei die Anpassung der Cargo. toml-Datei, bei der im [lib]-Abschnitt der crate-type auf cdylib gesetzt wird. Das bedeutet, dass Rust ein dynamisch ladbares und interoperables Binary erzeugt, das keine Rust-internen Formate wie .
rlib verwendet, sondern eine Art interoperables Design hat, welches sich gut für WebAssembly eignet. Will man zum Beispiel eine einfache Additionsfunktion schreiben, so sieht diese zunächst wie gewohnt aus: pub fn add(left: usize, right: usize) -> usize { left + right } Zwar sichtbar im Rust-Modul system, genügt dies aber nicht, um die Funktion in der finalen Wasm-Datei verfügbar zu machen. Ohne weitere Anpassungen löscht der Linker nicht erreichbare Funktionen aus, was bei nicht explizit exportierten Funktionen passiert. Das bedeutet, man muss den Export explizit angeben, um sicherzugehen, dass diese Funktion auch in der finalen WebAssembly-Datei nicht verloren geht. Exportieren von Funktionen Um Funktionen aus Rust in WebAssembly tatsächlich sichtbar und nutzbar zu machen, ist das Setzen der #[no_mangle]-Attributs essenziell. Es verhindert, dass Rust den Funktionsnamen in der Binärdatei verändert.
Allerdings reicht dies allein nicht, wenn man nicht auch explizit die Export-Symbole angibt. Zusätzlich ist die Verwendung von extern "C" sinnvoll, denn dadurch wird ein stabiles Application Binary Interface (ABI) verwendet – das C-ABI ist standardisiert und ändert sich nicht über Rust-Versionen hinweg – und stellt sicher, dass Parameter über die WebAssembly-Grenzen hinweg korrekt interpretiert werden. Das Ergebnis sieht so aus: #[no_mangle] pub extern "C" fn add(left: usize, right: usize) -> usize { left + right } Nach erneutem Kompilieren lässt sich die Funktion problemlos aus JavaScript oder anderen WebAssembly-fähigen Umgebungen aufrufen. Das Nutzen der nativen WebAssembly-API von JavaScript erlaubt es, die exportierten Funktionen mit einfachem Import-Objekt zu instantiieren und zu verwenden.
Importieren von Funktionen in Rust-WebAssembly-Module Interessant wird es, wenn Rust-Code nicht nur exportierte Funktionen zur Verfügung stellt, sondern Funktionen aus der Umgebung importieren will. WebAssembly-Module laufen in einer Sandbox und haben standardmäßig keinen Zugriff auf Host-APIs. Um dennoch beispielsweise Zufallswerte oder andere Systemfunktionen zu verwenden, muss man Importe deklarieren. In Rust geschieht dies durch extern-Blöcke mit speziellen Attributen wie #[link(wasm_import_module = "NameDerImportGruppe")]. Standardmäßig werden solche Funktionen als unsafe behandelt, da Rust keinerlei Gewähr über das Verhalten externer Funktionen geben kann. Ein Beispielimport könnte folgendermaßen aussehen: #[link(wasm_import_module = "Math")] extern "C" { fn random() -> f64; } Diese Funktion lässt sich anschließend in Rust-Aufrufen nur innerhalb eines unsafe-Blocks aufrufen.
Um die Handhabung sicherer und eleganter zu gestalten, empfiehlt es sich, Wrapper-Funktionen in Rust zu erstellen, die diesen unsafe-Code kapseln und ein sicheres Interface bereitstellen. Das Import-Objekt in JavaScript muss dann die erwartete Struktur liefern, also zum Beispiel das JavaScript-Math-Objekt mit einer random-Funktion übergeben. Grenzen bei komplexen Typen Wesentliche Stolperfallen treten beim Austausch komplexer Datentypen zwischen Rust und WebAssembly auf. Die WebAssembly-Spezifikation definiert nur einfache Zahlentypen wie i32, i64, f32, f64. Höherwertige Rust-Typen wie Strings, Arrays oder Vektoren müssen daher manuell in simple Speicherbereiche übersetzt werden, was ohne Hilfswerkzeuge wie wasm-bindgen kompliziert wird. Die Parameter und Rückgabewerte von extern zugänglichen Funktionen sollten daher möglichst auf diese primitiven Typen begrenzt werden, um mögliche ABI-Inkompatibilitäten und fehlerhafte Speicherzugriffe zu vermeiden.
Wer komplexe Datentypen nutzen möchte, muss sich mit der Speicherverwaltung, Pointern, Slice-Metadaten und manchmal sogar virtuellen Tabellen (VTables) auseinandersetzen. All das erfordert tiefere Kenntnisse der Speicherrepräsentation von Rust und WebAssembly. Speicherverwaltung und das no_std-Konzept Ein großer Unterschied zwischen Rust auf einer typischen Plattform und Rust für WebAssembly liegt in der zur Verfügung stehenden Laufzeitumgebung. Standardmäßig setzt Rust auf die Standardbibliothek std, die viele Abstraktionen und Dienste bereitstellt – inklusive Speicherverwaltung, I/O und Fehlerbehandlung. In WebAssembly aber existiert oft kein Betriebssystem, kein Dateisystem, keine automatische Speicherverwaltung. Insbesondere beim Kompilieren für wasm32-unknown-unknown fehlt eine unterstützende Laufzeitumgebung. Daher ist in vielen Fällen die Verwendung von #!
[no_std] notwendig, das bewirkt, dass die Standardbibliothek nicht eingebunden wird, sondern nur das Kernpaket core, das nur elementare Sprachfeatures enthält. Ohne std fehlen jedoch wichtige Funktionen wie Heap-Allokation, Umgang mit Panics oder komplexe Datentypen wie String und Vec. Wer sie dennoch nutzen möchte, kann das alloc-Crate einbinden, das die allokationsbezogenen Typen und Funktionen bereitstellt, benötigt aber dann eine eigene Speicherallokation. Für die Speicherverwaltung ist es nötig, entweder eine eigene Allokator-Implementierung anzubieten oder eine bestehende zu benutzen. Eine einfache Variante ist ein sogenannter Bump-Allocator, der einen großen Speicherblock verwaltet und in nur eine Richtung immer weiter Vergabe durchführt, ohne jemals Speicher freizugeben. Diese Vorgehensweise ist einfach und performant, doch für komplexe Anwendungen mit viel Speicherumschichtung nicht geeignet.
Rust verlangt beim no_std-Kompilieren außerdem zwingend einen panic_handler, eine Funktion, die definiert, was passiert, wenn ein Programm an einer Stelle panikt. In einem WebAssembly-Modul kann das bedeuten, eine Endlosschleife zu durchlaufen oder einen Trap auszulösen, zum Beispiel über core::arch::wasm32::unreachable(), was die WebAssembly-Engine sofort stoppt. Optimierungen für kleine Dateigrößen Die Größe des WebAssembly-Moduls hat großen Einfluss auf Ladezeiten und Performance im Browser. Unnötige Debug-Symbole und große Standardbibliotheken können die Modulgröße unnötig aufblasen. Rust bringt vordefinierte Profiling-Optionen mit, die man in der Cargo. toml-Datei anpassen kann. Das Aktivieren von LTO (Link-Time Optimization) ist ein wirkungsvoller Schritt, um die Größe und die Performance zu verbessern. Es ermöglicht dem Compiler, auf Linker-Ebene Code korrekt zu trimmen und überflüssige Zweige und Funktionen zu entfernen.
Der Befehl cargo build --release sollte grundsätzlich genutzt werden, damit keine Debuginformationen enthalten sind. Zusätzlich kann man ein Strippen der Debuginformationen mit [profile. release] strip = true im Cargo. toml steuern. Tools wie wasm-opt von der Binaryen-Suite erlauben noch darüber hinausgehende Optimierungen direkt an der WebAssembly-Binärdatei. Komplexe Hilfsmittel wie twiggy helfen dabei, Modulgrößen zu analysieren und versteckte Übergrößen zu entdecken. Warum sind manche WebAssembly-Module aus Rust so groß? Ein weiteres gängiges Problem sind Panics und das vermehrte Einfügen von internem Fehlerbehandlungs- und Formatierungscode durch Rust. Das kann passieren, wenn zum Beispiel in Funktionen standardmäßige Bounds-Checks nicht kontrolliert oder mit eigenen Prüflogiken ersetzt werden. Auch unbedachte Verwendung von Strings und Fehlerbehandlungen führt oft zu einer Aufblähung.
Rust-Entwickler sollten daher besonders bei WebAssembly-Code ohne Runtime verstehen, wie sie Fehler- und Randbedingungen am besten selbst absichern und verhindern, dass unnötige Panics ausgelöst werden. Fazit Die direkte Kompilierung von Rust zu WebAssembly ohne auf Werkzeuge wie wasm-bindgen zurückzugreifen, ist anspruchsvoll, eröffnet aber ein tieferes Verständnis und Kontrolle über den Kompilierungsprozess und das entstehende Modul. Es bietet eine großartige Gelegenheit, die Eigenheiten der WebAssembly-Plattform kennen zu lernen und schlanke, performante Module zu produzieren. Wer Komplexität reduzieren und Module für den produktiven Einsatz optimieren will, sollte die Kontrolle über Exporte, Importe, ABI-Stabilität, Speicherverwaltung und Optimierungen nutzen. Gleichzeitig helfen moderne Tools wie wasm-opt, LTO und Analysewerkzeuge diese Optimierungen praktisch umzusetzen.
Für alle, die Rust und WebAssembly in ihrer reinsten Form verstehen und einsetzen wollen, ist der „harte Weg“ also eine Bereicherung, auf dem viel Lernpotenzial steckt und der gleichzeitig die Grundlage für fundierte Entscheidungen in der Praxis schafft.
