I feel like the weather app makes a lot of sense from a corporate politics point of view.
A 1mb weather app would have a significantly less impressive pie chart associated with it come "here are our improvements" presentation.
Also if times get tough and you're told to reduce headcount by 10%, who do you want to get rid of. Sally who knows the USB driver end to end or Todd who wrote the bloated 1gb weather app. (Don't feel bad for Todd, he knew what he was getting himself into.)
I've been doing forest service stuff for a year with almost no signal and often no gps without antenna and it's incredible what asks for location permission to run. My amazon bought LEDs (15+, 3-5 diff types) all check location before I can connect them. I wind up waiting 30 seconds sometimes more to turn lights on. My generator and inverter have to phone home so that lags constantly.
Also I've been shadowbanned from a bunch of social media sites and had problems with payment systems, etc because Starlink confuses companies tracking user locations to geoips etc.
Won't even get into the apps that look downloaded and usable until you open them with no signal and they don't work before phoning home.
I've been meaning to go through ALL my apps and delete everything I don't use, I haven't installed a new app in years.
Then you have MacOS now that has the most "wtf" level permission prompts that make you think everything is phoning home or trying to access stuff on your network when it's just connecting bluetooth devices or something daily. I don't know how many games I've installed that now show up as having full screen or keyboard control permissions just to use input devices. I work on this stuff and can deduce what it's doing, especially after googling it, but "Stupidgame needs control of your system" is wild to someone who doesn't, I'm sure.
I've been wondering if it's almost nefarious that they want to get people used to allowing these seemingly system wide controls to be given to.. everything, by hiding the security-ok things behind a giant red flag warning.
Sorry went on a tangent. I miss specific permissions notifications I can trust.
I just looked and I think what I'm talking about, where they folded more specific permission callouts under a broad term "Full disk access" "local devices" etc used to be more granular before they updated that UI to match the iphone. If I got a jumpscare permission prompt on macos, I used to actually be concerned. Now they're all jumpscares for basic stuff.
But I could be misremembering. I haven't liked any of the recent macos releases. I will begrudgingly install Golden Gate to hopefully fix my m1 max 64gb slowing ot a crawl with Tahoe.
Did Todd just know or did his PO tell him to add telemetry tool number 24 while he was protesting and begged to be allowed to migrate to a newer rendering library but got shot down promptly because "KPI line must go up"? :)
Todd was a script kiddie and never really knew what he was doing. He changed careers after the layoff and is now an owner of an electrical contracting business.
That's less because of what it's implemented in - and more to do with all the tracking and libraries they want to reuse...
BigCo apps will take up lots of space and memory for BigCo reasons - obviously less if it's in Rust vs Go vs Python, but you could easily write Go apps that use far less memory than Rust apps written at BigCo due to BigCo reasons.
It's just not really that much of a priority for them to have their weather app use less than 1GB of memory. It's a far bigger priority for someone to insist that somebody else uses some bloated framework so they can get promoted.
The things that unsafe enables are arbitrary pointers, FFI, and accessing union members in a C struct. It seems highly unlikely to me that unsafe would fix any beginner's problem.
.clone() on the other hand is indeed an easy/quick fix for a lot of issues you'd face when learning rust.
I think beginner programmers are unlikely to use unsafe when learning rust but people coming from c or c++ who are beginners at rust might use unsafe all over the place.
Exactly - we have been using C or C++ for decades and most of us have a lot of experience. We think like programmers in the languages meaning we often do things that Rust won't allow without unsafe. A small percent of the time that is the right thing (which is why Rust have unsafe), but very often there is a Rust way that is just as performant if only we knew how to think like Rust programmers.
Sadly it still feels like it's one of the languages where the language doesn't trust you, it tries to force you to do things "the right way". I do love quite a few of its design like how traits are, not forcing every method into the declaration, and the standard library is much less crazy than the C++ version.
Sadly, other things a bit less so - the story for the thin battery-less stdlib + npm-style churn encourages bloat, and the semantics are obsessed with safety at a heavy cost to productivity unless you spam clone() and reference-counting - but then your program becomes slow, kind of negating the advantages, you might as well have written it in C# or something...
Yes, but this this is not a problem at all because any bug caused by misuse of unsafe (or unwrap) is entirely the fault of the programmer (or the AI) and not of Rust. /s
A headwind makes it harder to advance in the direction you're going. I think you might have meant to say "there is a strong tailwind towards memory safety".
It would be possible for me to give a more nuanced take, but the upshot is: none of that shit is going to work 100%.
One may get local maxima like an unsafe bonanza, or something that introduces a custom runtime memory management discipline at the cost of performance etc. Fully equivalent C++ to Rust in full generality is mainly wishful thinking. Of course that does not mean one should not try it.
Oh, I 100% agree. The question is how much you can reduce the effort of the port/migration, and in particular the validation effort.
I've worked on projects where the core bits of code was "90%" converted by some automated tool, and in my view the overall benefit to the project timeline was probably only 20-30% because of the Amdahl's-law-type overheads of validation and bits of code not supported by the automation/conversion process. Nice, but no silver bullet.
Non-idiomatic porting also isn't super-helpful if the resulting code isn't maintainable.
I hope announcements like this show that Rust is not a fledgling little language that moves fast and breaks things anymore. It's a mature, serious competitor to well established languages like C++ and C#. This is particularly important when trying to compare the experience of using Rust to other languages in the "better C/C++" space like Zig and Odin -- these are much newer and have more rough edges than Rust.
This is very big news, all major OS vendors that also have a role in C and C++ language tooling, now have diversified their options in systems programming languages for greenfield development.
Additionally we finally get some public news about the MSVC integration rumors regarding Rust.
COM and WinRT (basically COM Next) are the way to do cross language Interoperability in Windows since VB 5 replaced VBX with OCX, it was a key feature in .NET Framework design, and revamped on Windows 8, when WinRT was introduced as the original design for .NET (Ext-VOS).
This is from rustconf. A lot of the focus at Rustconf this year has been C++ interop, Python Interop, Javascript interop -- it's no longer about "rewrite it in rust", it's about being part of the ecosystem.
Good. As a C+++ programmer Rust has some things that intrigue me. However I have no desire to rewrite everything in rust and so interoperability has been what is holding me back.
We rewrote everything a few years back, completing in 2014 (Rust 1.0 came in 2015) - it costs nearly a billion dollars! I cannot in good conscience go back to management and ask for another billion dollars to rewrite again (Rust might be more productive, but inflation will eat that up, so I expect a rewrite to be more expensive). If Rust can work with my existing code though - I know of a number of small places where there is reason to rewrite anyway because the code is bad (or sometimes was good but not nicely flexible for the features we have added since).
Because it takes time. Even with coding agents, to add the capability. Then, there is the question on whether Rust developers who like to engage with Microsoft tools, would really consider Visual Studio as their IDE, instead of something like VS Code, VS Code Agent Mode, GitHub Copilot App, or GitHub Copilot CLI with simpler editors.
I'd be curious to know whether Rust developers believe Visual Studio is the right place for Microsoft to invest Rust specific coding capabilities.
There's two ways to approach this — build tooling for existing Rust developers to get them to adopt the Microsoft stack, or build tooling for existing Microsoft stack developers to get them to adopt Rust.
I'd argue that the former is less important than the latter, and my understanding is that Visual Studio is still the IDE for Windows-centric development, so for those MS-first developers, Rust missing from VS means Rust is poorly supported, end of story.
It would have to be the 2nd option. Who in their right mind would voluntarily choose Windows as their dev env? It will have to be those who are already there.
Most people don't have a choice. Corporate IT has choosen what I run my machine on. I have used a native linux machine, but since my email is still on outlook, everybody uses teams, and all the non-code documents are on windows I end up having to have a windows machine. Linux in a VM under windows ends up being the easiest workflow (though I'm just starting to try WSL and so far it is looking good)
This kind of stuff is why its hard to have good conversations about tooling. Windows is the best place for many kinds of software dev, but perhaps not the kind you are doing.
Visual Studio brings a lot to the table for C++ development. Specifically the Debugger, although IntelliSense also often succeeds at queries that stump clangd.
If they can replicate that capability, I think it can be a draw.
I was a mac / Linux guy before my current gig, but Visual Studio is so much more capable than XCode that I basically only use the Windows machine except to debug mac-specific issues. Less so, now, admittedly, that the malware scanner process is literally always pegging a CPU core.
Optimistic to assume that modern day programmers even know what a debugger is, or if they do, consider it as anything else than some weird ancient shibboleth only used by the greybeards ;)
To be fair, even before LLMs could spot my bugs in an instant I really only regularly used debuggers in C because it can't display arbitrary types in debug print statements.
Debuggers still have their place in algorithm heavy work, or to pull apart heap dumps to try and figure out obscure bugs.
Even LLMs use debuggers. I asked Claude to reverse engineer a closed source binary the other day. It used gdb to trace its behaviour. Didn’t even use ghidra.
But of a tangent but I think cognitive skills are starting to become like physical skills. If we don’t move our bodies, we waste away physically. If we don’t do hard cognitive work sometimes - like writing and debugging code - I worry our minds will atrophy.
I don’t have a problem with cars. But walking is still good for us.
Try, but what skills are work keeping? We need something cogntive, but not everything. I know a few people who blacksmith as a hobby (often for the physical exercise as much as the work), but most people are happy not knowing how to do that job. I know how to set the air-fuel ratio on a gas engine, but I'm glad I don't need to tweak those parameters while driving (unlike a 1910s car where you did), and I won't miss oil changes on my cars as I move to electric.
You have it already on VSCode, which isn't quite the same, however nowadays it is an open question which one is more relevant for Microsoft's management, especially given that VS isn't cross platform (see Azure), and is stuck with WPF/.NET Framework.
println!() already works, who needs more than that?
Kidding aside, VS Code has excellent debugging support already. Unless you need to share your Rust code base with a legacy C/C++ code base, I don't think VS is the best environment for Rust programming.
There are good use cases for staying within full-fat VS's capability set (drivers, among other things), but I don't think Microsoft needs to add Rust to VS in this much of a hurry.
While literally true, the phrasing of this title will certainly and (IMO) purposefully confuse some headline scanners vs: “Rust Is a Tier-1 Language at Microsoft”.
I love how World of Warcraft "gear tier" jargon has expanded into the rest of the world. Pre-Y2K, the pseudo-formal usage of "tier-N" wasn't widespread in the US.
I remember an other 1 tier language ms once had. Anyone remember Visual-J?
On the other hand if we could code in rust and get windows.forms as a ui it might make sense. MS is burning UI layer faster than one can train on
The type system and error handling ergonomics make it easier to write defect-free code than, say, Go or Java.
Simple servers are request scoped and mostly feature linear request handling, so you're writing simple vanilla Rust without the complex pointer semantics that you would use for systems programming. The async pieces aren't difficult either.
Serde-annotated structs are the best serialization/deserialization story anywhere. It integrates super ergonomically into Axum and Actix to make writing request handlers a breeze. They're super easy to read, too.
Compared to what? I see ASP.NET Core and Quarkus very competitive. The virtual threads in Java are great, paired with structured concurrency IMHO.
If I have to go microservice or API, I would choose FastAPI for fastest delivery and if I have to rewrite, Go, unless it is massive scale and scaling horizontally becomes a headache I would not consider Rust/C++ for this.
All the backend, etc. for the company I have been working for is C++ for the fast parts but all tools around are Python (with NiceGUI and Flask mostly).
It could as well be the opposite, but Rust does not need a proof of quality today, certainly not from Microsoft. Still, becoming Tier 1 in major trillion-dollar corporations (Microsoft, Meta, Amazon, and I know Google also has efforts in that direction) is something.
This “Tier-1 language” engineering status for Rust means giving internal teams a paved path from local development to production: secure toolchain builds, productive developer tooling, quality workflows, deep platform integration, and compliance with the SDL requirements Microsoft software must meet.
Specifically, it joins a list of existing Tier 1 languages (C++, C#, and TypeScript), as "one of the best-supported languages for internal development at Microsoft"
Tier 1 is the summit of summits - the summum bonum of languages, the highest order to which a language can aspire. Very few ever attain it. Non multa, sed multum: not many, but only those of extraordinary quality. Most languages remain forever in Tier 3, never passing beyond its gates. Of these, scarcely 1% ascend to Tier 2. And from that already distinguished company, a mere 0.1% possess the refinement, depth, and excellence required to cross the final threshold into Tier 1.
Consider what that means: Tier 1 represents roughly the top 0.001% of languages. Pauci sed electi - few, but chosen. The crème de la crème. The aristocracy of languages. Primus inter pares, yet standing at the very edge of what programming language greatness can be.
Ad astra per aspera. Through hardship, to the stars. Tier 1 is not merely another rank: it is the ultima Thule, the farthest frontier, the crown, the apotheosis.
Yes, about as good as a language that is 40 years old, and was also (like Rust) 10 years old when becoming Tier 1 inside Microsoft, while there were far less alternatives.
I hope this kind of thing means Rust stops making so many rapid breaking changes in th compiler. I've tried it twice, once in early 2021 once 2025. Both times I tried to compile a few random projects I found on the web, stuff like a wordpress fanfic scraper, a software defined radio program, etc.
In 2021 my linux distro I was using had just been released 3 months prior but it's rustc already could not compile 2 of 3 projects due to the use of new features added to rustc in those 3 months. In the SDR case I knew the author and he was able to re-write it in more general rust code and it worked great. In 2025 my linux distro had been out for a couple years. None of the rust projects I tried would compile with my rustc.
Rust, in the past, seemed a very bleeding edge, move fast and break things community. I hope that with more people using it in more places the demographics change and people won't always target latest and greatest. A lifetime for the compiler of at least a few years would make it a very useable language. Adoption at microsoft might help this.
It sounds like you are not running into breaking changes, you are just running into projects that like to use new features that are not available in your older compiler.
You can compile any old code with newer rustc as long as old project does not use unstable features that have changed/went away. What are you on? I recently recompiled project from 2015 with latest stable rust just fine.
All breaking changesin rust done via editions and you can mix-and-match editions.
I suspect GP is using system rustc to build random projects off of github and doesn't use one of the distros that actually updates rustc, like Fedora, SuSE or Arch.
Then the conversation is about forward compatibility, whether developers should wait X amount of time before using new std APIs or features, and whether the ease of using rustup and project expectation of it being accessible is reasonable or not.
We thought your Rust.NET comment was somewhat in jest. No, Microsoft isn't porting Rust to .NET, they barely try to support anything other than C# on it nowadays, but the article mentions an internal adapter for MSVC codegen.
The project linked above has been posted to HN in the past a few times though.
You gotta have balls or be receiving tons of money to publicly celebrate the sloppiest software company of the decade making your programming language Tier 1 internally.
This is great! Hope this trend will continue in the future; using a memory-safe language should be a top priority imo in context of the coming rogue AI swarms.
Yeah I'd written some rust ~ 10 years ago when the language was very different and that led me to believe that it was a 'great within it's niche' sort of thing for a long time, but after spending the last couple of years with it as a daily driver I think it's a pretty great general-purpose language.
The one really common gotcha with rust is that when trying to write concurrent code, newbies tend to throw Arc<RwLock<T>> goo around everywhere, and they end up with the world's shittiest garbage collector.
It is interesting to see the different patterns used due to different cases and tastes. For example, my concurrency patterns rarely use locks, and are instead usually one of:
- Dedicated hardware via DMA, multiple cores/MCUs etc
- Thread pools (e.g rayon)
- GPU
- SIMD
- Atomics
- Interrupts and their ISRs
- Event loops
- std::sync Thread and MPSC (My Std rust default for not blocking the GUI etc)
Most of it comes down to avoiding shared data. Unfortunately it requires forethought to do that well. There are also many cases where you do want to share data for optimal performance as other options are ultimately too heavyweight.
Also worth noting that an event loop by itself doesn't give you serialization by itself, it can just allow you to gain concurrency without parallelism. You still need some form of serialization by way of something like actors (or async locks).
I've said for a while that the main reason Rust is so popular is that it has a lot of effort put into the developer experience, with the low-level safety honestly not being all that important to a large portion of the programmers who would be fine with a garbage collector. I used to think that maybe a "Rust with garbage collector" would come along, but at this point it honestly seems more likely that an optional garbage collector would be added to Rust (probably with just the primitives in std and leaving it up to libraries to provide a more full experience, like with async runtimes).
Rust's async can be very lightweight depending on the runtime implementation. tokio and embassy are both runtimes but former is a throughput-optimized heavily multi-threaded while latter is a simple cooperative multitasking for embedded. We use both at my day job. Even 64k flash and 16k ram is enough for embassy.
Rapid prototyping is almost a meme at this point. If you are hand rolling code old school, you will waste more time shoehorning JavaScript and python semantics into rust code and end up with worse quality that takes more time rather than writing it from rust.
People did this a lot when rust was not as popular but there are plenty of very good rust programmers now who understand the language and can make programs that are significantly more performance for a marginal development cost.
Script ability can also be done in rust, Notably Zed (rust ide/vscode whatevers) is written in rust, and all the plugins are compiled to WASM, sandboxed and loaded.
Go is pretty nice for server-side API but if your application share types between boundries then rust is better
> Rapid prototyping is almost a meme at this point
> People did this a lot when rust was not as popular but there are plenty of very good rust programmers now who understand the language and can make programs that are significantly more performance for a marginal development cost.
Why isn't the game industry moving to it then? Bc it just cannot compete at volubility with C++, among other things. Yes, you can have skilled people, but the borrow checker is still there and that is an anti-change-me-fast fact of life. I think things like sending batches of info to the GPU in casted ways, alignment, etc. all go against safety naturally but this is fundamentally what needs to be done anyway when transfering data to the GPU, so adding a layer of safety for the sake of doing it to notice that your data-oriented pipeline has to suddenly change its shape would mean repeating work...
Namely, Rust is just not good at this. Rust is good if you can replicate a safe layer that is very reusable every time (when interacting with unsafe) or when you do not need unsafe at all or hardly, where you can take advantage of its safety fully.
Also, there are certain very tweaked data structures such as Boost.MultiIndex or linked lists with intrusive hooks and others that are not easy at all in Rust and they do have value in some situations. I had some of this in some telecommunication systems before.
Someone in that industry can perhaps speak to it, but I have two cents of perspective...
I have helped a young person with gamedev interests try to learn rust (on Windows). They've learned some rust, but the graphics+Windows libraries and primitives to work with are not very good nor straightforward, even with AI assistance. Besides weakness in the gaming/rendering domain, there seemed to be some very real versioning/dependency hell that also didn't help.
It's massively easier to make progress on even just a 2D game with something like GDScript-based Godot (or Unity or...).
> Why isn't the game industry moving to it then? Bc it just cannot compete at volubility with C++, among other things.
I have no opinion regarding rust suitability as a game language, but your answer doesn't sound right.
The actual reason is much simpler. The industry is built on a handful of game engines. Those engines are extended or scripted in C++ or C#. Thus the vast, vast majority of the work force will only have experience with those languages and the entirety of game studios' tooling is built around those. The end.
I don't think "volubility" means what you think it means. The usual meaning of "voluble" is "talkative" (gesprächig if your username is accurate). I'm not quite sure what you're going for here or in an earlier comment, but suspect it's something more like "ergonomic", i.e. the language being easy/natural to write and not getting in your way.
No, rapid development is essential when you're making games. It's not a "solved science", sure you can code something up and slap some programmer art on it then ship it but you very well know that won't be usable. You need to iterate on the gameplay and gamefeel a lot if you want something more than slop.
One way is sure the native language + embedded scripting language combo but that's got the trap of impedance mismatch i.e. you spend all your time making engine not game then it overruns. But in any case having a way to iterate fast is a hidden productivity superpower, look at how many game studios have Live++ licences on their webpage;)
Rust is great for rapid protoyping, IMO. Or, at least the subset of rapid prototyping that involves massive rewrites to try out different approaches. Rust has a saying "if it compiles, it works", the compiler really ensures that you don't miss something when doing that rewrite.
My employer company go through JavaScript, Java, Golang and at the end landed on Rust for srver side and don't want to change anything. Everything is Rust now, regardless of traffic.
I don't know why you think it's only usable but this is your right.
Rust is great for GPU programming, or at least for writing the Host (CPU) side without friction. WGPU or FFI-based Vulkan etc bindings for graphics. Cudarc + normal Cuda kernels for general purpose compute. I bring these up as they're easy-to-use and mature.
Oh, its good at doing desktop applications these days? Which GUI libraries are good these days? Some native win32 binding? Are there good equivalents for Qt?
I'm interested in getting back to native application development; the job is on Electron right now and it's… meh.
Good news they adopted Rust as Tier-1 language. I hope their Weather app stop consuming more than 1GB RAM https://www.notebookcheck.net/Windows-11-s-built-in-Weather-...
I feel like the weather app makes a lot of sense from a corporate politics point of view.
A 1mb weather app would have a significantly less impressive pie chart associated with it come "here are our improvements" presentation.
Also if times get tough and you're told to reduce headcount by 10%, who do you want to get rid of. Sally who knows the USB driver end to end or Todd who wrote the bloated 1gb weather app. (Don't feel bad for Todd, he knew what he was getting himself into.)
Also, showing the weather is a great excuse to ask permissions for the user location.
I've been doing forest service stuff for a year with almost no signal and often no gps without antenna and it's incredible what asks for location permission to run. My amazon bought LEDs (15+, 3-5 diff types) all check location before I can connect them. I wind up waiting 30 seconds sometimes more to turn lights on. My generator and inverter have to phone home so that lags constantly.
Also I've been shadowbanned from a bunch of social media sites and had problems with payment systems, etc because Starlink confuses companies tracking user locations to geoips etc.
Won't even get into the apps that look downloaded and usable until you open them with no signal and they don't work before phoning home.
I've been meaning to go through ALL my apps and delete everything I don't use, I haven't installed a new app in years.
Then you have MacOS now that has the most "wtf" level permission prompts that make you think everything is phoning home or trying to access stuff on your network when it's just connecting bluetooth devices or something daily. I don't know how many games I've installed that now show up as having full screen or keyboard control permissions just to use input devices. I work on this stuff and can deduce what it's doing, especially after googling it, but "Stupidgame needs control of your system" is wild to someone who doesn't, I'm sure.
I've been wondering if it's almost nefarious that they want to get people used to allowing these seemingly system wide controls to be given to.. everything, by hiding the security-ok things behind a giant red flag warning.
Sorry went on a tangent. I miss specific permissions notifications I can trust.
i prefer the macos mindset if not the actual OS
I just looked and I think what I'm talking about, where they folded more specific permission callouts under a broad term "Full disk access" "local devices" etc used to be more granular before they updated that UI to match the iphone. If I got a jumpscare permission prompt on macos, I used to actually be concerned. Now they're all jumpscares for basic stuff.
But I could be misremembering. I haven't liked any of the recent macos releases. I will begrudgingly install Golden Gate to hopefully fix my m1 max 64gb slowing ot a crawl with Tahoe.
Did Todd just know or did his PO tell him to add telemetry tool number 24 while he was protesting and begged to be allowed to migrate to a newer rendering library but got shot down promptly because "KPI line must go up"? :)
Todd was a script kiddie and never really knew what he was doing. He changed careers after the layoff and is now an owner of an electrical contracting business.
The longer I work in corporate, the wiser Todd seems
In this day and age, both Sally and Todd are expendable. Both have been silently training their replacement by feeding the data models.
Replaced by LLM and an offshore contractor. CaPiTaLiSm, right?
The problem is the Webview2 prevalence, and note many Rust projects love their webviews as well.
That's less because of what it's implemented in - and more to do with all the tracking and libraries they want to reuse...
BigCo apps will take up lots of space and memory for BigCo reasons - obviously less if it's in Rust vs Go vs Python, but you could easily write Go apps that use far less memory than Rust apps written at BigCo due to BigCo reasons.
It's just not really that much of a priority for them to have their weather app use less than 1GB of memory. It's a far bigger priority for someone to insist that somebody else uses some bloated framework so they can get promoted.
Calling the Weather app an 'app' is doing all the Win32, WPF, WinForms and WinUI developers a huge disservice.
It is essentially an entire Chromium instance around msn.com/weather.
Whether vibecoded Rust will be better than whatever they are doing now remains to be seen.
The question in terms of memory is, will vibe coded rust get around ownership issues by .clone()-ing everything.
Maybe this has changed since I wrote Rust, but that was a classic beginner fix. Just throw memory at it.
https://github.com/luser/keep-calm-and-call-clone
"Keep calm and call clone" is a good strategy for getting things working. Don't prematurely optimize code until you know it's the bottleneck.
The other things I've seen beginners do is throw unsafe at everything.
The things that unsafe enables are arbitrary pointers, FFI, and accessing union members in a C struct. It seems highly unlikely to me that unsafe would fix any beginner's problem.
.clone() on the other hand is indeed an easy/quick fix for a lot of issues you'd face when learning rust.
I think beginner programmers are unlikely to use unsafe when learning rust but people coming from c or c++ who are beginners at rust might use unsafe all over the place.
Exactly - we have been using C or C++ for decades and most of us have a lot of experience. We think like programmers in the languages meaning we often do things that Rust won't allow without unsafe. A small percent of the time that is the right thing (which is why Rust have unsafe), but very often there is a Rust way that is just as performant if only we knew how to think like Rust programmers.
Sadly it still feels like it's one of the languages where the language doesn't trust you, it tries to force you to do things "the right way". I do love quite a few of its design like how traits are, not forcing every method into the declaration, and the standard library is much less crazy than the C++ version.
Sadly, other things a bit less so - the story for the thin battery-less stdlib + npm-style churn encourages bloat, and the semantics are obsessed with safety at a heavy cost to productivity unless you spam clone() and reference-counting - but then your program becomes slow, kind of negating the advantages, you might as well have written it in C# or something...
Yes, but this this is not a problem at all because any bug caused by misuse of unsafe (or unwrap) is entirely the fault of the programmer (or the AI) and not of Rust. /s
But Tier-1 app consuming Tier-1 RAM seems officially approved.
And that the calculator does not take 5 seconds to load
Those interested in this may find the following articles of interest:
Microsoft goals to convert 1 billion lines of code to rust by 2030 via automated tooling enabling "1 engineer, 1 month, 1 million lines of code": https://thenewstack.io/microsofts-bold-goal-replace-1b-lines...
DARPA work towards automating converting C code to Rust using a mix of 6 different teams using different approaches: https://www.darpa.mil/research/programs/translating-all-c-to... Feb 2026 Progress report: https://github.com/DARPA-TRACTOR-Program/Reports/blob/main/F...
That is not "Microsoft goals", that is "one employee's LinkedIn comment of his personal goal".
There have also been repeated statements from NSA & CISA that they recommend all development should be done in memory safe languages.
It's abundantly clear that there is a strong headwind towards memory safety, whether that's Rust or GC'd languages.
A headwind makes it harder to advance in the direction you're going. I think you might have meant to say "there is a strong tailwind towards memory safety".
You're right, I better do a 360 on my comment ;)
It would be possible for me to give a more nuanced take, but the upshot is: none of that shit is going to work 100%.
One may get local maxima like an unsafe bonanza, or something that introduces a custom runtime memory management discipline at the cost of performance etc. Fully equivalent C++ to Rust in full generality is mainly wishful thinking. Of course that does not mean one should not try it.
See also my other comment.
Oh, I 100% agree. The question is how much you can reduce the effort of the port/migration, and in particular the validation effort.
I've worked on projects where the core bits of code was "90%" converted by some automated tool, and in my view the overall benefit to the project timeline was probably only 20-30% because of the Amdahl's-law-type overheads of validation and bits of code not supported by the automation/conversion process. Nice, but no silver bullet.
Non-idiomatic porting also isn't super-helpful if the resulting code isn't maintainable.
I hope announcements like this show that Rust is not a fledgling little language that moves fast and breaks things anymore. It's a mature, serious competitor to well established languages like C++ and C#. This is particularly important when trying to compare the experience of using Rust to other languages in the "better C/C++" space like Zig and Odin -- these are much newer and have more rough edges than Rust.
This is very big news, all major OS vendors that also have a role in C and C++ language tooling, now have diversified their options in systems programming languages for greenfield development.
Additionally we finally get some public news about the MSVC integration rumors regarding Rust.
Are you thinking this augurs more interoperability features in C?
Why should it?
COM and WinRT (basically COM Next) are the way to do cross language Interoperability in Windows since VB 5 replaced VBX with OCX, it was a key feature in .NET Framework design, and revamped on Windows 8, when WinRT was introduced as the original design for .NET (Ext-VOS).
https://arstechnica.com/features/2012/10/windows-8-and-winrt...
See windows-rs crate.
Good, C# is one of the worst languages there is, hopefully they turn it in to tier 18
The big news here is they've replaced LLVM with MSVC's backend.
This is from rustconf. A lot of the focus at Rustconf this year has been C++ interop, Python Interop, Javascript interop -- it's no longer about "rewrite it in rust", it's about being part of the ecosystem.
Good. As a C+++ programmer Rust has some things that intrigue me. However I have no desire to rewrite everything in rust and so interoperability has been what is holding me back.
We rewrote everything a few years back, completing in 2014 (Rust 1.0 came in 2015) - it costs nearly a billion dollars! I cannot in good conscience go back to management and ask for another billion dollars to rewrite again (Rust might be more productive, but inflation will eat that up, so I expect a rewrite to be more expensive). If Rust can work with my existing code though - I know of a number of small places where there is reason to rewrite anyway because the code is bad (or sometimes was good but not nicely flexible for the features we have added since).
If it is a tier-1 language why isn't it supported in Visual Studio?
Because it takes time. Even with coding agents, to add the capability. Then, there is the question on whether Rust developers who like to engage with Microsoft tools, would really consider Visual Studio as their IDE, instead of something like VS Code, VS Code Agent Mode, GitHub Copilot App, or GitHub Copilot CLI with simpler editors.
I'd be curious to know whether Rust developers believe Visual Studio is the right place for Microsoft to invest Rust specific coding capabilities.
There's two ways to approach this — build tooling for existing Rust developers to get them to adopt the Microsoft stack, or build tooling for existing Microsoft stack developers to get them to adopt Rust.
I'd argue that the former is less important than the latter, and my understanding is that Visual Studio is still the IDE for Windows-centric development, so for those MS-first developers, Rust missing from VS means Rust is poorly supported, end of story.
It would have to be the 2nd option. Who in their right mind would voluntarily choose Windows as their dev env? It will have to be those who are already there.
Most people don't have a choice. Corporate IT has choosen what I run my machine on. I have used a native linux machine, but since my email is still on outlook, everybody uses teams, and all the non-code documents are on windows I end up having to have a windows machine. Linux in a VM under windows ends up being the easiest workflow (though I'm just starting to try WSL and so far it is looking good)
> (though I'm just starting to try WSL and so far it is looking good)
WSL is really nice, as is Windows Terminal. I particularly love its fonts (but that's probably just me).
This kind of stuff is why its hard to have good conversations about tooling. Windows is the best place for many kinds of software dev, but perhaps not the kind you are doing.
Visual Studio brings a lot to the table for C++ development. Specifically the Debugger, although IntelliSense also often succeeds at queries that stump clangd.
If they can replicate that capability, I think it can be a draw.
I was a mac / Linux guy before my current gig, but Visual Studio is so much more capable than XCode that I basically only use the Windows machine except to debug mac-specific issues. Less so, now, admittedly, that the malware scanner process is literally always pegging a CPU core.
Visual Studio does have a really nice C++ debugger - one would imagine the C++ debugging capabilities should translate to Rust.
> Even with coding agents
Because of coding agents? :D
Given how long it took visual studio to get 64bit support, I wouldn't hold your breath!
( Edit: I should probably inform the layperson: It was Visual Studio 2022 )
It is, with extensions (using rust-analyzer of course). I don't know what's the status inside Microsoft.
Because it is already supported in VS Code.
I don't think this is a hot take, but I'm predicting Microsoft will gradually phase out Visual Studio in favor of VS Code.
Agreed but I think you need to pry Visual Studio from VB.NET developers' cold dead hands.
C++ developers, too. I suppose they're splitting out the real powerful stuff (Debugger, LSP) for VSCode's consumption.
So when will we get tier 1 debugging support in Visual Studio?
Optimistic to assume that modern day programmers even know what a debugger is, or if they do, consider it as anything else than some weird ancient shibboleth only used by the greybeards ;)
The greybeards rarely used debuggers, and then only to see the stack trace of a core file. They found printf better.
I can't find my copy of https://en.wikipedia.org/wiki/The_Practice_of_Programming but that is what I recall it says. Those authors are the best known greybeards.
To be fair, even before LLMs could spot my bugs in an instant I really only regularly used debuggers in C because it can't display arbitrary types in debug print statements.
Debuggers still have their place in algorithm heavy work, or to pull apart heap dumps to try and figure out obscure bugs.
Even LLMs use debuggers. I asked Claude to reverse engineer a closed source binary the other day. It used gdb to trace its behaviour. Didn’t even use ghidra.
Debugger MCP better
But of a tangent but I think cognitive skills are starting to become like physical skills. If we don’t move our bodies, we waste away physically. If we don’t do hard cognitive work sometimes - like writing and debugging code - I worry our minds will atrophy.
I don’t have a problem with cars. But walking is still good for us.
Try, but what skills are work keeping? We need something cogntive, but not everything. I know a few people who blacksmith as a hobby (often for the physical exercise as much as the work), but most people are happy not knowing how to do that job. I know how to set the air-fuel ratio on a gas engine, but I'm glad I don't need to tweak those parameters while driving (unlike a 1910s car where you did), and I won't miss oil changes on my cars as I move to electric.
It’s all /skills now
You have it already on VSCode, which isn't quite the same, however nowadays it is an open question which one is more relevant for Microsoft's management, especially given that VS isn't cross platform (see Azure), and is stuck with WPF/.NET Framework.
I'd also love to see MS sponsoring Windows support for a modern linker like mold or wild.
lld-link is already a big step up from link.exe. Although the latter has incremental linking, which none of the Unix-like linkers have.
to be fair mold or wild's full link is a few hundred times faster than a link.exe incremental relink
println!() already works, who needs more than that?
Kidding aside, VS Code has excellent debugging support already. Unless you need to share your Rust code base with a legacy C/C++ code base, I don't think VS is the best environment for Rust programming.
There are good use cases for staying within full-fat VS's capability set (drivers, among other things), but I don't think Microsoft needs to add Rust to VS in this much of a hurry.
RustRover, my friend.
But which GUI toolkit will they use for all their new rust applications?
Is Microsoft still trying to embrace, extend, extinguish Netscape after all those years? :-)
You’ll know when they publish Visual R++ or Rust.NET.
Don't forget about R#
I was originally going to write that, but R# already exists: https://rsharp.net/ (based on https://www.r-project.org/)
Not to be confused with the other R#, which is ReSharper.
https://www.jetbrains.com/resharper/
you jest but F# already does the ocamlness of Rust, no? and you don't need a borrow checker.
For tracking ownership of non-memory resources you still need something like that.
I guess we should watch for contributions to Servo
I guess the big question is whether they are going to open up rustc_codegen_utc for use outside of Microsoft?
They responded in the Zulip threads that yes, this is the plan, although they don't know if and what things will be open-source yet.
From the linked Zulip thread (https://rust-lang.zulipchat.com/#narrow/channel/131828-t-com...):
> We are running different workloads including rustc perf suite. In general the runtime performance is on par with llvm.
Not what I would've expected!
While literally true, the phrasing of this title will certainly and (IMO) purposefully confuse some headline scanners vs: “Rust Is a Tier-1 Language at Microsoft”.
I love how World of Warcraft "gear tier" jargon has expanded into the rest of the world. Pre-Y2K, the pseudo-formal usage of "tier-N" wasn't widespread in the US.
I remember an other 1 tier language ms once had. Anyone remember Visual-J? On the other hand if we could code in rust and get windows.forms as a ui it might make sense. MS is burning UI layer faster than one can train on
Fable migrated a Go/Wails project for me to Rust/GPUI and it's so much faster, there is the possibility of Rust to gobble up many more projects.
Site down, maybe they need port it to use Rust...
They use wordpress
What is wrong with wordpress exactly?
there are a lot of really bad plugins that are used. Also there are a lot of really bad admins who have out of date versions that are misconfigured.
Matt Mullenweg
wordpress
A lot of infrastructure is going to be ported to Rust.
It's fantastic for websites and servers, and LLMs are very good at generating it.
The primary downside of Rust is the long compile times, especially with macros (serde, etc.) If that can be fixed, it will be sublime.
I like Rust a lot but I'm not sure it would come very high up my list for web applications.
Axum and Actix are phenomenal web frameworks.
The type system and error handling ergonomics make it easier to write defect-free code than, say, Go or Java.
Simple servers are request scoped and mostly feature linear request handling, so you're writing simple vanilla Rust without the complex pointer semantics that you would use for systems programming. The async pieces aren't difficult either.
Serde-annotated structs are the best serialization/deserialization story anywhere. It integrates super ergonomically into Axum and Actix to make writing request handlers a breeze. They're super easy to read, too.
Say more. I need me proper rust in the browser.
> Axum and Actix are phenomenal web frameworks
Compared to what? I see ASP.NET Core and Quarkus very competitive. The virtual threads in Java are great, paired with structured concurrency IMHO.
If I have to go microservice or API, I would choose FastAPI for fastest delivery and if I have to rewrite, Go, unless it is massive scale and scaling horizontally becomes a headache I would not consider Rust/C++ for this.
All the backend, etc. for the company I have been working for is C++ for the fast parts but all tools around are Python (with NiceGUI and Flask mostly).
I think the combination is quite powerful, btw.
First compile. Every another will be significantly faster since compiler is incremental
Visual Rust sounds like a defect but I'm looking forward to it.
The text is mostly about rustc_codegen_utc; maybe this should be reflected in the title?
Also the use of italics there is rather jarring.
Being technically approved by Microsoft is not a proof of quality...
It could as well be the opposite, but Rust does not need a proof of quality today, certainly not from Microsoft. Still, becoming Tier 1 in major trillion-dollar corporations (Microsoft, Meta, Amazon, and I know Google also has efforts in that direction) is something.
ermm... which are the rust-native libs which enable winrt3.0 native apps?
Link doesn’t work.
What’s a Tier 1 language?
(Link worked for me ...)
This “Tier-1 language” engineering status for Rust means giving internal teams a paved path from local development to production: secure toolchain builds, productive developer tooling, quality workflows, deep platform integration, and compliance with the SDL requirements Microsoft software must meet.
Specifically, it joins a list of existing Tier 1 languages (C++, C#, and TypeScript), as "one of the best-supported languages for internal development at Microsoft"
Tier 1 is the summit of summits - the summum bonum of languages, the highest order to which a language can aspire. Very few ever attain it. Non multa, sed multum: not many, but only those of extraordinary quality. Most languages remain forever in Tier 3, never passing beyond its gates. Of these, scarcely 1% ascend to Tier 2. And from that already distinguished company, a mere 0.1% possess the refinement, depth, and excellence required to cross the final threshold into Tier 1.
Consider what that means: Tier 1 represents roughly the top 0.001% of languages. Pauci sed electi - few, but chosen. The crème de la crème. The aristocracy of languages. Primus inter pares, yet standing at the very edge of what programming language greatness can be.
Ad astra per aspera. Through hardship, to the stars. Tier 1 is not merely another rank: it is the ultima Thule, the farthest frontier, the crown, the apotheosis.
The answer I deserved!
It means it's about as good as C++ ;)
Yes, about as good as a language that is 40 years old, and was also (like Rust) 10 years old when becoming Tier 1 inside Microsoft, while there were far less alternatives.
Seems pretty good to me ;)
(I know you're joking).
It means a language for the very elite special force unit. In MSFT, that means the Ads teams will be able to serve you Ads in excel very quickly. /s
crazy i like that
I hope this kind of thing means Rust stops making so many rapid breaking changes in th compiler. I've tried it twice, once in early 2021 once 2025. Both times I tried to compile a few random projects I found on the web, stuff like a wordpress fanfic scraper, a software defined radio program, etc.
In 2021 my linux distro I was using had just been released 3 months prior but it's rustc already could not compile 2 of 3 projects due to the use of new features added to rustc in those 3 months. In the SDR case I knew the author and he was able to re-write it in more general rust code and it worked great. In 2025 my linux distro had been out for a couple years. None of the rust projects I tried would compile with my rustc.
Rust, in the past, seemed a very bleeding edge, move fast and break things community. I hope that with more people using it in more places the demographics change and people won't always target latest and greatest. A lifetime for the compiler of at least a few years would make it a very useable language. Adoption at microsoft might help this.
It sounds like you are not running into breaking changes, you are just running into projects that like to use new features that are not available in your older compiler.
You can compile any old code with newer rustc as long as old project does not use unstable features that have changed/went away. What are you on? I recently recompiled project from 2015 with latest stable rust just fine.
All breaking changesin rust done via editions and you can mix-and-match editions.
I suspect GP is using system rustc to build random projects off of github and doesn't use one of the distros that actually updates rustc, like Fedora, SuSE or Arch.
Then the conversation is about forward compatibility, whether developers should wait X amount of time before using new std APIs or features, and whether the ease of using rustup and project expectation of it being accessible is reasonable or not.
does it mean there is a rust.net?
There is a rustc_codegen_clr which transpiles to .NET
https://github.com/fractalfir/rustc_codegen_clr
> This project is still early in its developement. Bugs, crashes and miscompilations are expected. DO NOT USE IT FOR ANYTHING SERIOUS.
how can one claim it is tier-1?
Also random student, nothing official from Microsoft.
We thought your Rust.NET comment was somewhat in jest. No, Microsoft isn't porting Rust to .NET, they barely try to support anything other than C# on it nowadays, but the article mentions an internal adapter for MSVC codegen.
The project linked above has been posted to HN in the past a few times though.
That project is not in any direct way related to Microsoft
Just had a PTSD flashback...
The year was 2002, VB6 had just been retired for VB.NET which had 0 backward compatibility.
And then we all became Flash/AS3 developers.
The End
As much as I like Rust. Still sad that F# didn't get this much support from their own mother.
Now their broken slop code is at least memory safe.
You gotta have balls or be receiving tons of money to publicly celebrate the sloppiest software company of the decade making your programming language Tier 1 internally.
Probably the fact they're a $3.7tn company has something to do with it.
This is great! Hope this trend will continue in the future; using a memory-safe language should be a top priority imo in context of the coming rogue AI swarms.
With certain rough edges like complex traits and Async aside, rust is an S-tier lang in several domains. Of interest:
It's not a memory-safety one-trick pony; it's a well-rounded lang which has learned from its predecessors.Yeah I'd written some rust ~ 10 years ago when the language was very different and that led me to believe that it was a 'great within it's niche' sort of thing for a long time, but after spending the last couple of years with it as a daily driver I think it's a pretty great general-purpose language.
The one really common gotcha with rust is that when trying to write concurrent code, newbies tend to throw Arc<RwLock<T>> goo around everywhere, and they end up with the world's shittiest garbage collector.
Give me something like boost.multiindex for Rust, and maybe I could think of trying some experiments.
I think C++ is an excellent choice due to its volubility actually. Bc when I want safety, I mostly have it (but I have done a lot of C++, admittedly).
yeah, locks are expensive.
It is interesting to see the different patterns used due to different cases and tastes. For example, my concurrency patterns rarely use locks, and are instead usually one of:
Most of it comes down to avoiding shared data. Unfortunately it requires forethought to do that well. There are also many cases where you do want to share data for optimal performance as other options are ultimately too heavyweight.
Also worth noting that an event loop by itself doesn't give you serialization by itself, it can just allow you to gain concurrency without parallelism. You still need some form of serialization by way of something like actors (or async locks).
Yeah, I primarily use rust because it's got algebraic data types, pattern matching, and cargo.
If ocaml had a cargo like experience, then I would migrate there.
I've said for a while that the main reason Rust is so popular is that it has a lot of effort put into the developer experience, with the low-level safety honestly not being all that important to a large portion of the programmers who would be fine with a garbage collector. I used to think that maybe a "Rust with garbage collector" would come along, but at this point it honestly seems more likely that an optional garbage collector would be added to Rust (probably with just the primitives in std and leaving it up to libraries to provide a more full experience, like with async runtimes).
a rust with gc is already available. it is called c# and runs on all os nowerdays
All those applications area sensitive to asynchronous programming.
Rust's async can be very lightweight depending on the runtime implementation. tokio and embassy are both runtimes but former is a throughput-optimized heavily multi-threaded while latter is a simple cooperative multitasking for embedded. We use both at my day job. Even 64k flash and 16k ram is enough for embassy.
Honestly, the only domains that I think rust isn't suitable for are:
* rapid-prototyping, where javascript and python are still top-tier
* adding scriptability to existing programs, where lua and scheme (and python) are popular
* Server-side API implementation (rust is usable here, but I think Go fits the slot better)
Rapid prototyping is almost a meme at this point. If you are hand rolling code old school, you will waste more time shoehorning JavaScript and python semantics into rust code and end up with worse quality that takes more time rather than writing it from rust.
People did this a lot when rust was not as popular but there are plenty of very good rust programmers now who understand the language and can make programs that are significantly more performance for a marginal development cost.
Script ability can also be done in rust, Notably Zed (rust ide/vscode whatevers) is written in rust, and all the plugins are compiled to WASM, sandboxed and loaded.
Go is pretty nice for server-side API but if your application share types between boundries then rust is better
> Rapid prototyping is almost a meme at this point
> People did this a lot when rust was not as popular but there are plenty of very good rust programmers now who understand the language and can make programs that are significantly more performance for a marginal development cost.
Why isn't the game industry moving to it then? Bc it just cannot compete at volubility with C++, among other things. Yes, you can have skilled people, but the borrow checker is still there and that is an anti-change-me-fast fact of life. I think things like sending batches of info to the GPU in casted ways, alignment, etc. all go against safety naturally but this is fundamentally what needs to be done anyway when transfering data to the GPU, so adding a layer of safety for the sake of doing it to notice that your data-oriented pipeline has to suddenly change its shape would mean repeating work...
Namely, Rust is just not good at this. Rust is good if you can replicate a safe layer that is very reusable every time (when interacting with unsafe) or when you do not need unsafe at all or hardly, where you can take advantage of its safety fully.
Also, there are certain very tweaked data structures such as Boost.MultiIndex or linked lists with intrusive hooks and others that are not easy at all in Rust and they do have value in some situations. I had some of this in some telecommunication systems before.
Why isn't the game industry moving to rust?
Someone in that industry can perhaps speak to it, but I have two cents of perspective...
I have helped a young person with gamedev interests try to learn rust (on Windows). They've learned some rust, but the graphics+Windows libraries and primitives to work with are not very good nor straightforward, even with AI assistance. Besides weakness in the gaming/rendering domain, there seemed to be some very real versioning/dependency hell that also didn't help.
It's massively easier to make progress on even just a 2D game with something like GDScript-based Godot (or Unity or...).
> Why isn't the game industry moving to it then? Bc it just cannot compete at volubility with C++, among other things.
I have no opinion regarding rust suitability as a game language, but your answer doesn't sound right.
The actual reason is much simpler. The industry is built on a handful of game engines. Those engines are extended or scripted in C++ or C#. Thus the vast, vast majority of the work force will only have experience with those languages and the entirety of game studios' tooling is built around those. The end.
I work in gamedev. Here is a simple answer: proprietary gaming platforms have no plans to support Rust.
I don't think "volubility" means what you think it means. The usual meaning of "voluble" is "talkative" (gesprächig if your username is accurate). I'm not quite sure what you're going for here or in an earlier comment, but suspect it's something more like "ergonomic", i.e. the language being easy/natural to write and not getting in your way.
No, rapid development is essential when you're making games. It's not a "solved science", sure you can code something up and slap some programmer art on it then ship it but you very well know that won't be usable. You need to iterate on the gameplay and gamefeel a lot if you want something more than slop.
One way is sure the native language + embedded scripting language combo but that's got the trap of impedance mismatch i.e. you spend all your time making engine not game then it overruns. But in any case having a way to iterate fast is a hidden productivity superpower, look at how many game studios have Live++ licences on their webpage;)
Rust is great for rapid protoyping, IMO. Or, at least the subset of rapid prototyping that involves massive rewrites to try out different approaches. Rust has a saying "if it compiles, it works", the compiler really ensures that you don't miss something when doing that rewrite.
> Rust is great for rapid protoyping, IMO
If you have to iterate a lot the shape of your code... no, it is not any good at this...
My employer company go through JavaScript, Java, Golang and at the end landed on Rust for srver side and don't want to change anything. Everything is Rust now, regardless of traffic.
I don't know why you think it's only usable but this is your right.
I do think rust works there (as you clearly know), i just like Go's ergonomics for that exact task better, that's all.
GPU programming?
Rust is great for GPU programming, or at least for writing the Host (CPU) side without friction. WGPU or FFI-based Vulkan etc bindings for graphics. Cudarc + normal Cuda kernels for general purpose compute. I bring these up as they're easy-to-use and mature.
Yeah, you're still stuck with DSL's there, but not for lack of trying https://github.com/NVlabs/cuda-oxide
Oh, its good at doing desktop applications these days? Which GUI libraries are good these days? Some native win32 binding? Are there good equivalents for Qt?
I'm interested in getting back to native application development; the job is on Electron right now and it's… meh.
Calculate ackermann(4,4), make no mistakes.
M$ choosing Rust might be the strongest argument for picking Go instead
They strike different balances.
Rust is absolute performance, similar to C++. Go is deliver fast and get a very good performance to effort ratio.