Rust: Die guten und die schlechten Seiten

Michael Thomas

© Shutterstock/ampol sonthong

Manchmal geraten Entwickler an eine Programmiersprache, die sie in ihren Bann zieht und nicht mehr los lässt. Dem Programmierer Jimmy Cuadra ist genau dies mit der Multiparadigmen-Programmiersprache Rust widerfahren. In einem aktuellen Blogpost gewährt er einen interessanten Einblick in die Gefühlswelt eines Rust-Enthusiasten und preist die Vorteile der Sprache – ohne dabei die Schattenseiten auszublenden.

Das Gute …

Besonders angetan hat es Cuadra Rusts Typsystem: War er dank seines Ruby-Hintergrunds nach eigenen Aussagen ehemals ein glühender Verfechter automatisierter Tests, hat ihn seine Beschäftigung mit Rust zu der Überzeugung gebracht, dass vieles, was in dynamischen Sprachen eher qualvoll vonstatten geht, von der statischen Typprüfung und Rusts Compiler viel besser gelöst wird. Tests, so Cuadra weiter, werden dadurch zwar nicht überflüssig, allerdings muss man sich in dieser Hinsicht nur um die echte Logik sorgen. Entgegen anderslautender Meinungen empfindet er Rusts Typsystem nicht als restriktiv, sondern vielmehr ausdrucksstark: So kann man laut Cuadra mit nur wenigen zusätzlichen Worten sicherstellen, dass sich der Code wie erwartet verhält; gleichzeitig wird eine größere Klarheit beim Lesen und Überprüfen des Codes erreicht. Des Weiteren gibt Cuadra an, dass er bei Verwendung von Rust jeden Compilerfehler nicht als frustrierend, sondern befriedigend empfindet, da die ausgespuckten Meldungen meist auf Dinge (wie Laufzeitfehler) hinweisen, die er in einem Ruby-Programm nach eigener Aussage so nie bemerkt hätte.

In einer Sache ist Cuadra sich sicher: Dynamische Sprachen verbieten sich im Rahmen großer und komplizierter Programme. Diesen Umstand identifiziert er auch als Grund dafür, dass zahlreiche Entwickler aus dem Dunstkreis von Ruby, Python und JavaSript mittlerweile auf Go umgeschwenkt sind: Die Google-Systemsprache verleihe das selbe Gefühl von Geschwindigkeit und Produktivität und bringe zugleich Vorteile wie die statische Typisierung und Ahead-of-time-Kompilierung mit sich. Ein Enthusiasmus, den Cuadra nicht teilen kann: Entgegen der gängigen Meinung ist er etwa der Ansicht, das Go schwerer zu lesen als Rust ist. Zwar gibt er offen zu, dass Rust schwerer zu erlernen ist; allerdings sei Rust letztendlich deutlich lohnender. Go ist für Cuadra auch deshalb wenig attraktiv, da es seiner Ansicht nach zu wenig dafür tut, den Stand der Technologie voranzutreiben, soll heißen: Go im Grunde nicht mehr als das, was dem Nutzer auch von dynamischen Sprachen geboten wird. Neben einem mittelprächtigen Typsystem identifiziert er in der Verwendung des Data Race Detector zudem einen grundlegenden Fehler im Design der Sprache – in Rust hingegen sind, Ownership- bzw. Borrowing-Konzept sei Dank, Data Races bei Verwendung sicheren Codes kein Thema.

Zu guter Letzt ist Cuadra aufgrund eigener Erfahrungen der Ansicht, dass sich Rust – obwohl unter dem Label „Systemsprache“ laufend und eher für Low-Level-Anwendungen gedacht – genau so gut für High-Level-Programme eignet.

… und das weniger Gute

Nach all der Lobhudelei gesteht Cuadra allerdings auch ein, dass im Rust-Land nicht alles eitel Sonnenschein ist. Der augenfälligste Punkt ist für Cuadra der Mangel an Bibliotheken bzw. die Unausgereiftheit der existierenden, wofür er allerdings in erster Linie das geringe Alter des Ökosystems verantwortlich macht.

Besonders schmerzhaft sind für ihn zwei Umstände. Erstens der Mangel an einer Feature-kompletten und zuverlässige Kryptographie-Bibliothek, der dafür sorgt, dass sich Rust auf eben jene C-Bibliotheken stützen muss, die die Sprache eigentlich überflüssig machen will. Hier hat Go im Hinblick auf den Produktionseinsatz seiner Ansicht nach die Nase vorne: Zwar existieren einige Rust-Kryptographie-Bibliotheken (ring, Sodium Oxide), diese sind Cuadra zufolge jedoch noch weit von der Produktionsreife entfernt.

Zweitens (und schwerwiegender) der Mangel an einer Feature-kompletten und stabilen Serialisierungs-Bibliothek. Zwar war ursprünglich angedacht, die Serialisierung in den Rust-Compiler einzubauen, dies wurde aber, um die Sprache und Standardbibliothek so schlank wie möglich zu halten, für Rust 1.0 in eine externe Bibliothek (bzw., „Crate“, Rusts Synonym für Bibliotheken und Packages) ausgelagert (rustc-serialize). Mit Serde existiert ein Bibliothek, die sich Cuadra zufolge zur de-facto-Serialisierungsbibliothek entwickeln könnte, allerdings erfährt das Projekt im Gegensatz zu rustc-serialize keine bevorzugte Behandlung. Zudem nutzt Serde ein Compiler-Plug-in – und diese sind, so Cuadra, noch weit davon entfernt, als stabiles Feature durchzugehen; eine Nutzung mit stabilen Versionen ist nur über einen wenig eleganten Umweg (die Serde-Crate Syntex, die wiederum zu einer Myriade von Problemen führt) möglich.

Eingedenk aller angeführten Punkte fällt Cuadras Fazit denn auch zwiespältig aus: Sofern man sich generelle Kenntnisse darüber aneignen möchte, was gute Programmierung ausmacht, oder gerne am Aufbau eines noch jungen Ökosystems mitarbeiten will, kann man die Sprache seiner Ansicht nach bedenkenlos in die Arme schließen. Ist man hingegen ausschließlich auf Produktivität aus, sollte man seiner Empfehlung nach jedoch vorerst noch die Finger von ihr lassen.

Aufmacherbild: New and Oxide on Old Chains von Shutterstock / Urheberrecht: ampol sonthong

Verwandte Themen:

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: