Über 100 Projekt-Repositories bei Microsoft werden inzwischen mit dem alternativen Codegen-Backend rustc_codegen_utc gebaut. Die Zahl nennt das Unternehmen selbst in einem Gastbeitrag über den Stand seiner Rust-Integration. Der Text kündigt nichts an, er zieht Zwischenbilanz. Rust ist bei Microsoft kein Experiment mehr, sondern Teil der internen Standardausrüstung. Interessanter als die Frage, ob der Konzern auf Rust setzt, ist deshalb eine andere: wie er die Sprache in eine Plattform einbettet, die über Jahrzehnte auf C und C++ gewachsen ist.
Der Beitrag ist eine Standortbestimmung, kein Produktversprechen. Er erinnert daran, dass Mark Russinovich, CTO von Azure, schon vor Jahren eine Zukunft für nativen Code skizzierte, in der Rust eine zentrale Rolle spielt, und dass Microsoft seither viel Geld in die Unterstützung des Rust-Projekts gesteckt hat. Heute zählt Rust intern zu den bestunterstützten Sprachen, gleichrangig mit C++, C# und TypeScript. Wenn du außerhalb von Redmond arbeitest, ist eher spannend, was dieser Status technisch bedeutet und wo es weiter hakt.
Am einfachsten stellst du dir das als große Fabrikhalle vor. Darin stehen Maschinen, die über Jahrzehnte für C und C++ gebaut wurden: der Compiler MSVC, die Windows-ABI, Analyse- und Signierungswerkzeuge, Update- und Patch-Mechanismen. Rust ist neu eingezogen und soll an denselben Maschinen arbeiten, nicht in einer zweiten, parallel errichteten Werkstatt.
Was der Tier-1-Status bei Microsoft praktisch heißt
Tier-1 klingt nach Rangliste, ist aber ein Arbeitsbegriff. Er beschreibt den Engineering-Status, den eine Sprache intern genießt: Teams bekommen einen gepflasterten Weg von der lokalen Entwicklung bis in die Produktion. Dazu gehören reproduzierbare und abgesicherte Toolchain-Builds, brauchbare Entwicklerwerkzeuge, definierte Qualitätsworkflows, tiefe Plattformintegration und die Einhaltung der SDL-Anforderungen, also des Security-Development-Lifecycle-Programms, das jede Microsoft-Software durchlaufen muss. Wer intern Rust schreibt, muss also nicht selbst herausfinden, wie man einen Compiler vertrauenswürdig baut.
Der Unterschied zum Open-Source-Alltag ist erheblich. Eine Sprache außerhalb eines Konzerns lebt von dem, was die Community bereitstellt. Innerhalb von Microsoft muss sie zusätzlich den Prüf-, Freigabe- und Wartungsprozessen standhalten, die für ausgelieferte Software gelten. Tier-1 heißt deshalb nicht, dass Microsoft die Sprache besonders laut bewirbt. Es heißt, dass sie dieselben Erwartungen erfüllt wie die Sprachen, mit denen das Unternehmen seit Jahrzehnten arbeitet.
Warum MSVC der kritische Punkt ist
MSVC ist der native Plattform-Compiler für Windows, und das ist keine Nebensache. Compiler und Betriebssystem haben sich über Jahrzehnte gemeinsam entwickelt. Neue Sicherheitsmerkmale, neue Diagnosen, neue Optimierungen entstehen meist zuerst dort und werden dann breit verfügbar gemacht. Wenn Rust bei Microsoft von Firmware und Treibern über Kernel und Hypervisoren bis hin zu Microservices und Anwendungen wachsen soll, muss es an dieser Stelle mitspielen.
Die Anforderung im Beitrag ist deshalb doppelt formuliert. Erstens sollen neue Funktionen und Fähigkeiten der Plattform in beiden Sprachen verfügbar sein. Zweitens braucht es nahtlose Interoperabilität zwischen ihnen. Ohne diesen Anspruch entstünde für jede Windows-spezifische Fähigkeit eine zweite, parallele Implementierung allein für Rust. Das wäre teuer, langsam und fehleranfällig. Vermieden werden soll genau das.
rustc_codegen_utc: ein zweites Backend für rustc
Das zentrale Werkzeug für dieses Ziel ist rustc_codegen_utc, ein alternatives Codegenerierungs-Backend für rustc. Es gehört architektonisch zur selben Familie wie rustc_codegen_llvm, rustc_codegen_gcc und rustc_codegen_cranelift. Es dockt an dieselbe Backend-Schnittstelle an und verbindet die gemeinsame Compiler-Maschinerie von rustc mit dem MSVC-Backend, das im Beitrag UTC genannt wird. Rust bekommt damit einen zweiten Weg, aus Quellcode Maschinencode zu machen.
Die Fähigkeiten, die dadurch verfügbar werden, sind unspektakulär, aber zentral. Genannt werden hohe Kompatibilität mit dem Windows-Werkzeug-Ökosystem und der ABI, Härtung von Binärdateien und Code-Sicherheitsmerkmale, Prüfung und Wartung nach dem Linken einschließlich Hotpatch, nahtlose Interoperabilität für hybride Projekte, sprachübergreifendes Inlining und Optimierung samt SPGO, also profilgesteuerter Optimierung auf Basis gesammelter Laufzeitprofile, dazu Debugging und Crash-Dump-Analyse sowie Profiling, Diagnostik und Coverage-Messung.
Zwei Begriffe daraus brauchen eine Erklärung. Hotpatch heißt, Sicherheitslücken in laufenden Prozessen zu schließen, ohne den Dienst komplett neu zu starten. Die ABI wiederum ist der binäre Vertrag zwischen getrennt übersetzten Modulen: Wer sie bricht, bricht den gesamten Bau. Diese Dinge sind über Jahre im MSVC-Umfeld entstanden. Rust an dasselbe Backend anzuschließen heißt, diese Investition mitzubenutzen, statt sie nachzubauen.
Hybride Rust/C++-Projekte auf Windows
Auf anderen Plattformen ist das Problem bereits gelöst. Wer dort ein gemischtes Projekt aus Rust und C++ baut und den C++-Teil mit Clang übersetzt, landet für beide Sprachen auf derselben LLVM-Codegenerierung. Auf Windows war das lange nicht der Fall, weil MSVC dort der native Compiler ist. rustc_codegen_utc schafft nach Darstellung des Beitrags dieselbe gemeinsame Basis für Windows-native C++-Projekte. Ohne sie mischen sich Backends, und damit gehen Inlining über Sprachgrenzen, einheitliche Härtung und konsistente Diagnosen verloren.
Der Beitrag räumt allerdings selbst ein, dass Codegenerierung nur die halbe Miete ist. Die andere Hälfte liegt auf Sprachebene: FFI-Verträge, Bindings, unterschiedliche Sprachsemantiken und die Frage, wie Build-Systeme beider Welten zusammenspielen. Das sind keine Detailprobleme, sondern die eigentliche Arbeit. Verwiesen wird in diesem Zusammenhang auf die Interoperability Initiative der Rust Foundation, die den Problemraum strukturiert und die laufenden Bemühungen in der Community bündelt.
Der Nutzen der gemeinsamen Basis ist deshalb vor allem ein ökonomischer. Ein einheitlicher Codegen-Pfad senkt Wartungs- und Weiterentwicklungskosten, weil neue Fähigkeiten, Sicherheitsmerkmale, Diagnosen und Wartungstechniken auf einem gemeinsamen Fundament landen. Das ist operativ relevant, aber auch strategisch: Rust nimmt direkt an der Windows-nativen Engineering-Umgebung teil, statt daneben zu stehen.
Rollout: produktionsreif seit Anfang 2026, selbst gebaut seit Rust 1.90
rustc_codegen_utc ist nach Angaben des Beitrags das Ergebnis einer größeren Investition eines eigenen Teams in der Microsoft-Entwicklerabteilung. Produktionsreif sei es seit Anfang 2026, und seit Rust 1.90 werde es selbst gehostet, das heißt: der Compiler übersetzt sich mit seinem eigenen Backend. Es ist Teil einer breiteren internen Rust-Plattform, zu der abgesicherte Supply-Chain-Builds von rustc, der Standardbibliothek und den zugehörigen Werkzeugen gehören, dazu die Anbindung an lokale Entwicklungsumgebungen, an Produktionspipelines sowie an die üblichen Qualitäts- und Compliance-Workflows.
Die genannten mehr als 100 Projekt-Repositories sind kein Endstand, sondern eine Momentaufnahme. Laut Beitrag kommen wöchentlich weitere hinzu. Das Unternehmen beschreibt die Anstrengung ausdrücklich als Investition über den gesamten Engineering-Lebenszyklus: Beschaffung, Werkzeuge, Qualität, Sicherheit, Plattformintegration, Auslieferung und langfristige Betreuung. Wer wissen will, wie ernst es einer Organisation mit einer Sprache ist, sollte weniger auf Ankündigungen schauen und mehr darauf, ob sie Wartung und Compliance mitfinanziert.
Was das für dich bedeutet
Selbst wenn du nie mit MSVC zu tun hast, stecken zwei lehrreiche Punkte in der Sache. Erstens ist rustc kein monolithischer Übersetzer, sondern ein Compiler mit austauschbaren Backends: LLVM, GCC, Cranelift, MSVC. Die Sprache hängt damit nicht an einem einzigen Codegenerierungspfad. Dass nun ein weiterer hinzukommt, ist kein Bruch, sondern die Bestätigung eines Entwurfs, der diese Vielfalt von Anfang an vorgesehen hat.
Zweitens zeigt das Beispiel, wo die Arbeit wirklich liegt. Nicht im Übersetzen, sondern an den Rändern: ABI, Ausnahmebehandlung, Build-Systeme, Bindings, Wartbarkeit. Wer heute hybride Systeme plant, sollte diese Grenzflächen genauso sorgfältig entwerfen wie die eigentliche Logik. Der Beitrag verweist für Rückfragen auf ein eigenes Diskussionsthema im Zulip des Rust-Projekts. Die offenen Fragen sind ausdrücklich noch nicht alle beantwortet.
C++ bleibt auf Windows noch viele Jahre dominant, und der Beitrag sagt das selbst. Gemischte Projekte sind deshalb nicht ein Übergangszustand, sondern der Normalfall, mit dem du rechnen solltest. rustc_codegen_utc ist keine Abkündigung von C++, sondern das Eingeständnis, dass zwei Sprachen langfristig nebeneinander existieren und deshalb ein gemeinsames Fundament brauchen. Ob dieses Backend je außerhalb von Microsoft auftaucht, ist offen. Die Frage nach sauberer Interoperabilität wird dadurch jedenfalls nicht kleiner, sondern dringlicher.
Quelle: rustfoundation.org
