Drei Fragen und Antworten: Wann sollen JavaScript-Entwickler auf Rust umsteigen?

Rust ist angesagt – aber wer umsteigen will, muss sich auf einige Unterschiede einstellen. Welche Hürden und Vorteile winken JavaScript-Entwicklern?

In Pocket speichern vorlesen Druckansicht 85 Kommentare lesen

(Bild: iX)

Lesezeit: 5 Min.

Für viele Programmierer ist Rust die neue Lieblingssprache, etliche Projekte werden komplett neu in Rust geschrieben. Und dafür gibt es gute Gründe – die Sprache ist speichersicher, performant, modern und ausdrucksstark. Doch nicht immer fängt man bei null an. Wir haben mit Stefan Baumgartner, Softwarearchitekt und Entwickler, darüber gesprochen, wann sich der Umstieg von JavaScript und TypeScript lohnt und worauf Sie achten müssen.

Was ist die größte Umstellung für JavaScript-Programmierer beim Wechsel auf Rust – und warum?

JavaScript als dynamisch typisierte Sprache erlaubt sehr einfach Objekte zu erzeugen und zu manipulieren. Nicht selten erzeugt man ein leeres Objekt und fügt laufend neue Felder hinzu bzw. verändert die Struktur, um es den Gegebenheiten anzupassen. Das ist herrlich flexibel und entfernt allerlei Kopfzerbrechen, wenn man mal zwei Bibliotheken miteinander kompatibel machen muss. Auch mit TypeScript und dem strukturellen Typsystem bleibt diese Flexibilität.

Bei Rust gibt es fixe Typen und die sind nominell, sprich: Man muss Daten dem Typ exakt zuweisen. Man muss genau wissen, welche Daten man wohin gibt und als gesteigerten Schwierigkeitsgrad macht man sich auch regelmäßig Gedanken zu den Speicherbewegungen. Und das noch beim Compile-Vorgang, der normalerweise in JavaScript ausbleibt! Das ist mit Sicherheit die größte Umstellung. Auf der anderen Seite können sich Entwicklerinnen oder Entwickler sicher sein, dass nach dem Compile-Vorgang das Programm auch funktioniert, und – wenn sie die Kniffe rund um Error Handling drauf haben – auch stabil und fehlerfrei. Das ist ebenso eine Umstellung!

Wie wirken sich die Garbage Collectors (GC) denn auf die Performance aus und was kann man in der Hinsicht tun?

Das ist höchst unterschiedlich und kommt auf die Programmiersprache an. Grundsätzlich muss man festhalten, dass die Auswirkung auf die Laufzeitgeschwindigkeit minimal sein kann, dafür aber Faktoren beeinflusst. Eine Geschichte, die ich oft aus dem Live-Betrieb von Applikationen höre, ist, dass der Java-GC nur dann richtig performen kann, wenn die Heap Size auf mindestens 8 GByte gesetzt wird. So können ausreichend Objekte abgelagert werden und der GC arbeitet in den Zeiten, in denen sonst wenig auf dem Hauptprozessor los ist. Das gilt für einen Java-GC, nicht zwingend für alle, wohlgemerkt. Damit kriegt man auch in Java gute Performance hin, allerdings hat man nicht überall 8 GByte RAM zur Verfügung. Auch gibt es Techniken, mit denen man gezielt den GC triggern kann, das erfordert aber wieder Detailwissen.

Go hingegen rühmt sich mit ihrem GC oft in wenigen Nanosekunden alles weggeräumt zu haben, was herumliegt. Dafür ist Go halt auch eine Sprache mit bewusst wenig Ausdrucksmöglichkeiten und nur einem Concurrency Modell. Es gibt also auch da Einschränkungen. Wie bei allen ist der Garbage Collector nur ein weiteres Tool, das mit gewissen Trade-Offs einhergeht, genauso wie es Rust mit dem Ownership- und Borrowing-Modell macht. Auch in Rust gibt es mit Reference Countern eine Basisversion eines Garbage Collectors, der mit dem eigentlichen Speichermodell gut mitspielt. Der große Unterschied: Es liegt in der Hand der Entwicklerinnen und Entwickler, das richtige Werkzeug zu nehmen. Und es muss explizit sein, also für alle im Code ersichtlich, was passiert.

Generell ist für viele Projekte Rust derzeit die Sprache der Wahl, aber in welchen Bereichen wäre JavaScript denn besser?

Ich würde mir wünschen, dass Rust wirklich die Sprache der Wahl ist, gerade, wenn man die Stabilität und Ausdrucksstärke betrachtet. Leider ist das immer noch nicht der Fall – Neugierige können übrigens bei mir den Umstieg auf oida.dev erlernen. Tatsächlich muss ich bei der Frage vorsichtig sein, ich bin auch nach 3 Jahren immer noch in der Honeymoon-Phase mit Rust und finde die Sprache für alles fantastisch.

Allerdings würde ich keine Browser-Applikation damit schreiben, weil JavaScript dort nativ läuft. Auch sehe ich, dass die Schwelle zum einfachen Scripten für Shellprogramme oder Datentransformationsfunktionen in JavaScript viel niedriger ist. Bei Dynatrace arbeite ich an einem Projekt, wo Kundinnen und Kunden beliebige JavaScript-Workloads im Browser schreiben und nach Zeitplan in einer Serverless-Umgebung ausführen. Bis auf Python würde mir keine andere Sprache einfallen, die so problemlos den Zugang für solche Aufgaben ermöglicht. Die Serverless-Plattform hingegen ist allerdings in Rust geschrieben!

Herr Baumgartner, vielen Dank für die Antworten! Mehr Details, einen Vergleich der beiden Sprachen und viele Praxistipps für den Umstieg finden sich im Titel der neuen iX. Außerdem wirft das Juli-Heft, das ab sofort erhältlich ist, einen genauen Blick auf die Kombination .NET und Rust sowie Rust für Embedded-Systeme.

In der Serie "Drei Fragen und Antworten" will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(fo)