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.)

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.

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.

Whether vibecoded Rust will be better than whatever they are doing now remains to be seen.

If they can't do it with infinity budget and infinity AI, they're not going to be able to do it with that plus Rust.

Hilarious that the article is like "Apple's weather app is only 200MB!"

The day that OS vendors started abandoning native apps was a hilarious day.

But Tier-1 app consuming Tier-1 RAM seems officially approved.

It won't, that 1GB+ belongs to Microsoft's advertisers and their many video ads

And that the calculator does not take 5 seconds to load

Does it matter when one embeds web browser into their app?

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.

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.

>I hope announcements like this show that Rust is not a fledgling little language that moves fast and breaks things anymore

I see this on here a lot on this site, but Rust hasn't been that in over a decade. Rust's devotion to post 1.0 stability is massive and has involved some interesting design choices. I started writing run in 2015(?) and only hit one breaking change in the language. It was a niche bug in a macro that was fixed later in a later release.

Just watching hackernews you see lots of news about it, but these are additive and not breaking things. I was still writing lots of mio-style async code after async await was out. You don't have to adapt new style or libraries. I used to have a joke that you could tell a codebase's age based on the error handling libraries used, but even with that it was additive. Often multiple would exist in different parts of the same code base. "Oh wow, I've gone deep on this refactor.... I'm starting to see error_chain"

Rust 1.0 was in 2015. Most of these languages you're thinking of out of the Handmade Community didn't even start development until around the point Rust 1.0 shipped.

In theory Odin 2027, the 1.0 release of Bill's Odin language, is scheduled for, as the name suggests, early 2027. Zig does not have an announced 1.0 schedule, and who knows for the other two famous Handmade languages.

From the rash of "C++ successor" languages a few years ago, Carbon is still being worked on, Herb Sutter's "Cpp2" seems dead or at least in a coma, Hylo is probably also in a coma, it has several "Write this text" type blog posts, dated 2025 for example...

Indeed, unless you're using Safari, you're almost certainly using Rust code to read this webpage.

For me it was the inclusion in the kernel. That locks it in as here to stay

Are you thinking this augurs more interoperability features in C?

I'm quite skeptical of rust usage leading to anything that helps consumers. Microsoft managed to add arbitrary code execution to Notepad. And it all points to a total disregard of the end-user, not lack of talent or capacity.

There's a huge push for this from the big companies adopting Rust. Google has been developing https://github.com/google/crubit. The older cbdingen is still usable if more limited (it's what Firefox uses for some pretty involved interop).

There's an interop initiative by the Rust Foundation, there is a project goal to map the problem space, there was an effort to introduce an attribute (`#[rustc_splat]`) to allow calling overloaded functions, and there are various community-generated tools for more or less automated bindings generation.

Rust's raison d'être is to improve the confidence of the security-critical parts of your system. You don't need to rewrite all 30M lines of code to benefit from it, you just need to identify the 1% of your codebase with the greatest attack surface (e.g. any internet-facing string parser), cordon that part of the codebase off with a C ABI, and then convert that part to Rust. This is similar to how Firefox incorporates bits of Rust into its own C++ codebase over time (e.g. for parsing URLs).

ya our codebase is 30m lines of c++

I'm sure that's a requirement for being a "Tier-1" language.

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).

It's only tier-1 for internal Microsoft use.

And for all we know, it might be officially supported in their internal builds of 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.

It is, with extensions (using rust-analyzer of course). I don't know what's the status inside Microsoft.

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 )

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.

IDK about "tier 1" but I'll note I've used VS for debugging and profiling Rust binaries. I even wrote a tool to auto-generate a wrapper .sln so I can easily launch from VS: https://github.com/MaulingMonkey/cargo-vs

The main pain point IME was poor debugger visualizers for standard containers and enums. I fixed some of that for the standard containers by writing some natvis files for std: https://github.com/rust-lang/rust/issues?q=state%3Aclosed%20... . Admittedly, they broke a few times. They also weren't automatically included in the pdbs, so I wrote a crate for that: https://github.com/MaulingMonkey/natvis-pdbs . And then someone crated and stabilized #[debugger_visualizer] for rust itself, which can do the same job: https://doc.rust-lang.org/reference/attributes/debugger.html .

(...I should check on enum visualization, but I suspect it's still poor.)

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 ;)

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.

I'd also love to see MS sponsoring Windows support for a modern linker like mold or wild.

u dont debug rust mate if it compiles it works

RustRover, my friend.

You’ll know when they publish Visual R++ or Rust.NET.

I guess we should watch for contributions to Servo

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.

LOL!

WinUI (3) via Windows Reactor

What is wrong with wordpress exactly?

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.

In World of Warcraft, gear tier is an ordinal representing the raid tier the gear was made accessible in, not an indication of its importance/power.

VisualRust.NET Copilot

Do you mean winui3?

windows-rs

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.

(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.

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.

It means it's about as good as C++ ;)

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

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.

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.

There is a rustc_codegen_clr which transpiles to .NET

https://github.com/fractalfir/rustc_codegen_clr

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

They strike different balances.

Rust is absolute performance, similar to C++. Go is deliver fast and get a very good performance to effort ratio.

Probably the fact they're a $3.7tn company has something to do with it.

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.

All those applications area sensitive to asynchronous programming.

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.

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.

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)

Calculate ackermann(4,4), make no mistakes.