Die Ergebnisse der Umfrage „State of Rust Survey 2025“ liegen vor: Immer mehr Entwicklerinnen und Entwickler setzen Rust in ihrem Arbeitsumfeld ein, können zunehmend produktiver damit arbeiten und verwenden dafür fast immer das aktuelle, stabile Release. Allerdings ist nur eine knappe Mehrheit der Teilnehmer mit dem Tempo zufrieden, mit dem sich Rust weiterentwickelt. Befürchtungen gibt es auch dahingehend, dass Rust zu komplex wird, Developer wie Maintainer zu wenig Unterstützung erhalten und sich die Programmiersprache im Unternehmensumfeld nicht durchsetzen kann.

Produktives Arbeiten am liebsten mit dem stabilen Release

Mehr als die Hälfte der Befragten meint, dass es sich mit Rust produktiv arbeiten lässt (56,8 Prozent). Damit setzt sich ein Trend fort, denn bei der Vorjahresumfrage stimmten noch 53,5 Prozent dieser Aussage zu, während es im Jahr 2023 nur 47 Prozent waren. Leicht gestiegen, auf 55,1 Prozent, ist auch der Anteil der Entwicklerinnen und Entwickler, die Rust täglich einsetzen. Unter den am häufigsten genannten Alltagsproblemen stehen dabei langsames Kompilieren (27,3 Prozent) und hoher Speicherbedarf für Zielverzeichnisse (22,2 Prozent) an vorderster Stelle.

Mit 89,2 Prozent setzt die große Mehrheit der Rust-Developer auf das aktuelle stabile Release. Sorge vor einem Upgrade hat dabei fast niemand, denn 97,1 Prozent stimmen der Aussage zu, dass der Wechsel auf eine neue stabile Compiler-Version sehr einfach ist und höchstens geringe Code-Anpassungen erfordert.

Vorsichtiger ist man bei Nightly-Upgrades, denn 56,9 Prozent erwarten hier Probleme wie Compiler-Fehler. Warum man diese trotzdem nutzt, beantworten knapp 31 Prozent damit, dass sie ein bestimmtes Feature nutzen wollen, das noch nicht in der stabilen Version zur Verfügung steht. Die Nightly-Version wird auch eingesetzt, weil ein bestimmtes Tool sie erfordert (10,8 Prozent) oder weil eine Crate-Abhängigkeit besteht (8,5 Prozent).

Hauptsorgen: Hohe Komplexität und mangelnder Support

Knapp 60 Prozent sind mit dem Tempo zufrieden, mit dem sich Rust weiterentwickelt. Einem Viertel geht es indes zu langsam und 41,6 Prozent meinen sogar, dass Rust zu komplex wird. Die ausbleibende Unterstützung für Developer und Maintainer sehen 38,4 Prozent als Problem an, ein Punkt, der gegenüber dem Vorjahr (35,4 Prozent) sogar in der Umfrage gestiegen ist. Hier spiegelt sich offensichtlich eine allgemeine Überforderung, die viele Projektverantwortliche bemängeln, oft neuerdings auch im Zusammenhang mit zunehmendem AI-Slop.

Den Spitzenplatz unter den Zukunftssorgen nimmt aber die Befürchtung ein, dass Rust in der Technologiebranche zu wenig Einsatz findet (42,1 Prozent). Die Umfrage macht allerdings auch einen gegenläufigen Trend sichtbar. Im Unternehmensumfeld wird Rust häufiger für den produktiven Einsatz herangezogen (48,8 Prozent), ein klares Plus gegenüber den Jahren 2023 und 2022, in denen noch 45,5 Prozent beziehungsweise 38,7 Prozent der Befragten diese Beobachtung gemacht haben. Zudem gibt ein Viertel der Teilnehmer an, dass ihr Unternehmen Rust-Developer einstellen will. Vergangenes Jahr waren es 22 Prozent und 2021 noch 19,6 Prozent.

Beliebteste Stable-Features und eine Wunschliste

Unter den Stable-Features, die in den letzten 12 Monaten dazugekommen sind, verwenden Entwicklerinnen und Entwickler Let Chains (71,4 Prozent) und Async Closures (55,5 Prozent) am häufigsten. Auf dem dritten Platz landet Trait Upcasting mit 28,1 Prozent. Im Gegensatz dazu werden Features wie Naked Functions, Strict Provenance API und diagnostic::do_not_recommend kaum benötigt.

Für das nächste stabile Release wünschen sich die Teilnehmer, dass noch nicht implementierte oder den Nightly-Versionen vorbehaltene Features wie Generic Const Expressions, Const Trait Methods, Stable ABI und Portable SIMD Aufnahme finden.

VS-Code-Nutzung sinkt

Die beliebteste Entwicklungsumgebung für Rust bleibt Visual Studio Code, allerdings mit weiter sinkendem Anteil. Im Jahr 2022 war es für 61,7 Prozent der Entwicklerinnen und Entwickler der Editor der Wahl, jetzt nur noch für 51,6 Prozent. Bei den genutzten Paketmanagern und Crate-Quellen sind die Sympathien klar verteilt. Rust-Developer verwenden fast ausschließlich Cargo (97,5 Prozent) und beziehen ihre Crates überwiegend von crates.io (96,6 Prozent). Einen großen Anteil machen mittlerweile auch die Git-Repositories aus, die 46,2 Prozent der Teilnehmer nutzen.

Linux ist als Rust-Entwicklungsplattform weiterhin das OS der Wahl (75,2 Prozent). macOS und Windows bringen es zusammen auf einen Anteil von 61,4 Prozent. Ein ähnliches Bild zeigt sich bei den Zielplattformen. Hier liegt Linux mit 88,4 Prozent vorn, gefolgt von Windows mit 43,3 Prozent und macOS mit 30,7 Prozent.

Mehr als 7000 Umfrage-Teilnehmende

Die vom Rust Survey Team durchgeführte Online-Umfrage „State of Rust Survey 2025“ lief 30 Tage lang vom 17. November bis zum 17. Dezember 2025 und war in zehn Sprachen verfügbar. Den kompletten Fragebogen beantworteten 7156 Entwicklerinnen und Entwickler, von denen sich eine Mehrheit von 23,4 Prozent in den USA verortete. Mit 13,4 Prozent folgten Teilnehmer aus Deutschland auf Platz zwei. Frankreich, Großbritannien und China machen mit zusammen etwa 16 Prozent die Plätze drei bis fünf unter sich aus.

Insgesamt unterscheiden sich die Antworten zum großen Teil nur geringfügig von der Umfrage aus dem Jahr 2024, so ihre Urheber. Die gegenüber den Vorjahren leicht gesunkene Beteiligung führt das Survey-Team auf die größere Anzahl von Umfragen zurück, die 2025 über den Rust-Blog lanciert wurden.

Sämtliche Ergebnisse der Umfrage stehen im Rust-Blog bereit. Die Auswertung gibt es auch als 59-seitigen PDF-Report.

(who)

Das OpenWrt-Projekt hat die Version 25.12.0 der Open-Source-Router-Firmware veröffentlicht. Besonders stechen darin die zahlreichen unterstützten Geräte und der Wechsel auf eine neue Paketverwaltung hervor.

In den Release-Notes liefert OpenWrt einen Überblick über die Änderungen. Als wichtigen Punkt vorneweg nennen die Entwickler, dass das Upgrade von OpenWrt 24.10 auf 25.12 in vielen Fällen vom sysupgrade-Werkzeug unterstützt wird, das versucht, die Konfiguration mitzumigrieren. Dennoch sollten Upgrade-Willige zuvor ein Backup ihrer Konfiguration anlegen, raten die OpenWrt-Programmierer. An OpenWrt 25.12.0 haben die Entwickler über ein Jahr lang gearbeitet und kommen auf mehr als 4700 Quellcode-Commits seit Fassung 24.10. Der Codename „Dave’s Guitar“ soll der Erinnerung des im April 2025 verstorbenen Dave Täht dienen.

OpenWrt: Änderungen unter der Haube

Der Paketmanager wechselt vom alten opkg zu apk (Alpine Package Keeper). Wichtigster Grund dafür ist, dass das OpenWrt-opkg nicht mehr unterstützt und apk weiterhin gepflegt wird. Nur wenige Paketnamen haben sich geändert. Ein Cheatsheet soll beim Umsteigen hilfreiche Informationen liefern. Außerdem liefert OpenWrt nun eine webbasierte „attended.sysupgrade“-LuCI-App (ASU) mit. Auf Geräten mit größerem Flash-Speicher installiert OpenWrt außerdem das Kommandozeilen-Tool „owut“ (OpenWrt Upgrade Tool) standardmäßig mit. ASU soll auf neue OpenWrt-Versionen aktualisieren und Firmware-Images automatisch mit allen derzeit installierten Paketen zusammenbauen können. Dabei erhält es die Systemkonfiguration und erlaubt die Integration zusätzlicher installierter Pakete direkt in das SquashFS-Dateisystem. Das soll Upgrades deutlich vereinfachen: Mit nur wenigen Klicks in LuCI und nach kurzer Wartezeit steht ein angepasstes Firmware-Abbild bereit, das ohne weitere manuelle Eingriffe installiert wird.

Außerdem speichert OpenWrt in einem RAM-basierten Dateisystem den Befehlsverlauf der Shell. Der steht damit auch nach neuen Logins bereit. Das erspart unnötige Schreibzugriffe auf den Flash-Speicher, der nur eine begrenzte Zahl an Schreibzyklen verkraftet. Das lässt sich jedoch umstellen, sodass auch persistente Speicherung auf dem Flash-Speicher möglich ist. Das erhöht jedoch die Schreibzyklen und wirkt sich auf die Flash-Lebensdauer aus, warnen die Entwickler.

Hard- und Software-Unterstützung

Hardwareseitig gibt es mehr Unterstützung für Realtek-Ziele, dort insbesondere mehr Switch-SoCs mit 10-GBit-Support. Das qualcommax-Ziel unterstützt zwei weitere SoCs. Neu dabei ist ein siflower-Build-Target und neue Sub-Targets für Allwinner-F1C100/200s-SoCs. Ebenfalls neu dabei ist der Microchip LAN969x-Switch-Chipsatz. Insgesamt kommt OpenWrt nun auf mehr als 2200 unterstützte Geräte. Seit OpenWrt 24.10 sind 180 neu dazugekommen.

Die Software ist ebenfalls aktueller: Der Linux-Kernel 6.12.71 kommt für alle Build-Targets zum Einsatz, außerdem sind die Stände von glibc 2.41, gcc 14.3.0, binutils 2.44 dabei. Als zentrale Komponenten sind nun die Fassungen busybox 1.37.0, dropbear 2025.89 und dnsmasq 2.91 Bestandteil von OpenWrt. OpenWrt 24.10 erreicht mit dem Release von OpenWrt 25.12.0 in sechs Monaten das Support-Ende, also gibt es dafür nach September 2026 keine Sicherheitsupdates mehr. Nutzer sollten daher die Zeit nutzen und zeitnah auf die neue Version aktualisieren.

Ende Oktober musste das OpenWrt-Projekt Sicherheitslücken schließen. Die haben Angreifern etwa das Einschleusen und Ausführen von Schadcode oder das Ausweiten ihrer Rechte im System ermöglicht.

(dmk)

Google hat ein neues Kommandozeilenwerkzeug für Workspace veröffentlicht, mit dem Entwickler und Administratoren direkt auf Dienste wie Gmail, Drive, Calendar, Sheets und Docs zugreifen können. Die Google Workspace CLI (gws) steht als Open-Source-Software unter Apache-2.0-Lizenz und baut ihre Befehlsstruktur dynamisch aus dem Google Discovery Service auf. Innerhalb von wenigen Tagen nach Veröffentlichung Anfang März 2026 stieß das Projekt auf großes Interesse auf GitHub.

Das liegt auch an der technischen Ausrichtung: Das Werkzeug richtet sich sowohl an Nutzer als auch an KI-Agenten. Es unterstützt das Model Context Protocol (MCP), wodurch sich KI-Systeme wie Claude direkt mit Workspace-Daten verbinden können. Die CLI bringt mehr als 40 vordefinierte Agent-Skills mit, die Aufgaben wie E-Mail-Triage, Meeting-Vorbereitung oder Dateiorganisation automatisieren sollen. Entwickler können eigene Skills für ihre spezifischen Anforderungen erstellen.

Dynamische Befehlserstellung

Ein technischer Vorteil gegenüber herkömmlichen API-Clients liegt in der dynamischen Befehlserstellung: Die CLI lädt die Befehlsdefinitionen zur Laufzeit aus dem Discovery Service und speichert sie für 24 Stunden zwischen. In diesem Zeitraum stehen neue Workspace-API-Endpunkte automatisch zur Verfügung, ohne dass die Software aktualisiert werden muss. Das Werkzeug bietet zudem Funktionen wie Schema-Introspection, automatische Paginierung und strukturierte JSON-Ausgabe.

Die Installation erfolgt wahlweise über npm (npm install -g @googleworkspace/cli) oder als fertiges Binary. Alternativ lässt sich die in Rust entwickelte Software auch mit Cargo kompilieren. Die Authentifizierung unterstützt OAuth, Service Accounts und Domain Wide Delegation, wobei die Credentials mit AES-256-GCM verschlüsselt werden. Granulare Berechtigungen lassen sich über Google IAM und Service Accounts nach dem Least-Privilege-Prinzip konfigurieren.

Google kennzeichnet die Workspace CLI ausdrücklich als „nicht offiziell unterstützt“, obwohl das Tool von Google entwickelt wird. Die Workspace CLI unterscheidet sich von der 2025 veröffentlichten Gemini CLI, die als terminal-basiertes KI-Coding-Tool konzipiert ist. Weitere Informationen finden sich im GitHub-Repository des Projekts.

(fo)