It's less one guy's plan and more one Microsoft Research team's research goal to investigate technologies that might enable that in a few years. So probably more institutional support than just some guy, but less actually planning on succeeding in the full ambitious goal.

what's your point?

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

The recommendation is qualified for typical apps that do not have extreme performance or scale requirements. They use Java for many, many things.

C++ is still indicated for systems that are optimizing for performance and scalability characteristics, since it intrinsically requires a lot of "unsafe" constructs.

[flagged]

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 were "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.

As I pointed out in a sibling comment, the plan isn't for it to work. This is a job posting for a researcher at MSR to investigate what it might look like someday.

LLMs are unusually good at Rust; it's an optimization target. And the constraints provided by "successfully compile with the Rust compiler" make it work well for agent iteration.

(I have mixed feelings about that, but empirically it holds true.)

Most people it's good at syntax and the error messages give you a good loop. But the domains rust actually makes sense in tend to be quite punishing on slop both culturally and technically.

As an embedded dev, it still feels a decade away, at least. Rust is perfectly usable as a lang to make a little module that links into your main project as a .a file. But, as the language for your whole embedded codebase? Forget it. I have a litany of complaints including Cargo fuckery, ecosystem neglect, lack of first-party support, excessive code size, bad documentation, and bad IR that wastes stack by creating copies on immutable moves.

Don't get me wrong, Rust is lightyears ahead of any other alleged C/C++ successor. But I work in a space where C and C++ have been the only option for the last 30 years with absolutely no production-ready alternative. It looks like that won't be changing anytime soon, which is disappointing.

From what I could understand regarding Sean Parent's last interview at ADSP, Hylo is most likely not happening at all, given the raise of AI tooling, with Dave Abrahams re-focusing into non-computing related work going forward,

https://adspthepodcast.com/2026/08/21/Episode-300.html

Cpp2 was Herb's experiment and doesn't seem to be developed much further now,

https://github.com/hsutter/cppfront/discussions/1450

Google is still quite keen in having Carbon, for the purpose of migrating existing C++ codebases, for new code there is Rust, Go, Kotlin, Java, Swift and co.

"Carbon: graduating from the experiment - NDC Toronto 2026"

https://www.youtube.com/watch?v=WJl4ftb5Fxg&t=9

To Odin's credit, it is used for production software that _isn't_ a toy (by the language's own authors). It is probably 1.0 quality already.

> other two famous Handmade languages

Jai and... C3? FilC?

[dead]

Hah, I remember error_chain. One of my projects during an internship was upgrading a bunch of the old error handling libraries to the new things. I'm glad that corner of the ecosystem has stabilized now.

At that same job we hit a pretty nasty breaking change where mem::uninitialized() was deprecated and this turned out to cause a lot of critical async libraries to explode at runtime. But these sorts of things don't really happen anymore. The editions system is an excellent design and a big contributor to making the language and stdlib reliable.

Native AOT with C#/.net has come a long way, fwiw.

https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

Allegedly, there is Rust in macOS (but maybe not in iOS), so maybe it's true even if you're using Safari.

I would say it already is. But it takes time for all software to be rewritten in Rust.

I thought it got pushed back out? Wasn't there a big drama about this and Linus weighed in?

Linus is a wise operator at this point. I often see him come in like a hammer to bash down squabbling, but then he allows the situation to evolve once things quiet down. I only saw the hammer so I'm not sure what the current state is now.

Meh, I don't really trust TIOBE. It's at best a very noisy signal. And languages can end up on there for unusual reasons.

Rust supports opting into the C ABI

The complaint can be applied to any modern software, unfortunately.

Firefox is a virtual container that executes web applications safely. It’s too much memory still, but OTOH half an OS. It also doesn’t share anything with the OS like Safari

Vs2022 is a $1k a year product

Mainly purchased by companies not individuals and will be run on workstation pcs with a decent amount of RAM

So your complaints about 2gb are in the minority I would say, as most users don’t care. So it’s not a Microsoft priority.

After all, they are stupid enough to pay $1k a year for an IDE per seat!!!

clangd alone uses 6 GB when working with Chromium’s codebase. Code indexes can be very large, even for a simple application. Out-of-the-box IDEs must index the standard library and keep it in memory.

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.

What were you working on that cost a billion dollars to rewrite? Or was that hyperbole?

It's definitely been a meme in the rust ecosystem

(but yes, the language team and ecosystem were always making a point of incremental addition rather than full rewrite)

I must have a very active imagination then because I sure keep seeing rewrites of things in Rust

Eh, they call TypeScript a tier 1 language too.

Codegen was still done via LLVM. LLVM supports the MSVC _runtime_, here they're talking about using their (arguably worse) backend directly to generate code and do optimisations

Windows ecosystem, and all those things MSVC backend can do and LLVM does not.

For the same reason a Rust frontend is being developed for GCC.

    > Microsoft managed to add arbitrary code execution to Notepad.

    > And it all points to a total disregard of the end-user

Aight! Fable 5.1 summary says this is about Microsoft built, self-hosts, and runs in production a proprietary-backend codegen for rustc that bypasses LLVM on Windows. The vehicle is rustc_codegen_utc, an alternative rustc backend in the same family as the LLVM, GCC, and Cranelift backends, wired to the MSVC backend ("UTC").

Well that leaves up to almost 50% potentially not written in either language.

And little code can already have a big impact, e.g. react native in start menu coupled with edge running in the background

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.

Visual Studio does have a really nice C++ debugger - one would imagine the C++ debugging capabilities should translate to Rust.

> Because it takes time.

That's an excuse, not the reason.

IntelliJ RustRover has been around for years.

Similarly, VS Code has had Rust plugins written by the community in their spare time years ago.

> Even with coding agents

Because of coding agents? :D

This is a shocking news to me. Can you elaborate with sources?

Agreed but I think you need to pry Visual Studio from VB.NET developers' cold dead hands.

I hate VS Code (even though I use it regularly on Linux Mint) because it's basically "File Focused" not "Project Focused" or "Solution Focused."

Yeah, I know that it can read Visual Studio Projects and Solutions but these are kludges. It's essentially a souped-up file editor.

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.

Debugger MCP better

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.

I thought rover forced you to use their horrible new UI?

I know, haha. It's a bit of an absolute statement but as far as all of the features I look for in the context of creating scalable and maintainable software (especially in the age of agent-assisted coding) - Rust has been the most productive, least frustrating language I have worked with.

It's basically TypeScript but runtime exceptions are impossible. If it compiles, it works - so the _only_ thing you worry about is how you organised your code (abstractions, domains, etc) and if the logic is correct.

It saves a lot of time in PR reviews because you only really complain about logic or code organization.

By contrast, C#, Go, Java all have runtime exceptions for things like null pointers and race conditions. That means, when reviewing code, you have to be on the lookout for those things in addition to the logic and structure.

On the single threaded side, TypeScript is great, but JavaScript runtime performance and resource utilization is obscene. With Rust basically being TypeScript but without those limitations (and also natively supporting more frontend frameworks without transpilers), what is the use case for TypeScript (other than legacy software already being written in JavaScript or TypeScript)?

You can write Rust with your eyes closed and it'll probably work.

I do have fond feelings towards winforms and wpf from years ago, but I can't use it to write cross platform applications.

There really isn't anything other than web that covers that use case, sadly.

C# still has runtime exceptions and race conditions.

With Rust, once you figure out the borrow checker (which is honestly pretty simple), you're at least as productive but with fewer bugs

Win forms/WPF is essentially legacy, and using C# consumes much more resources than Rust (even for UI, see Windows Reactor C# vs Rust).

Additionally, I don't think C# is that simple anymore. By now it has so many features added and the list is still increasing this day. Rust is more difficult to get productive, but the actual language complexity isnt that big.

LLMS makes onboarding to Rust much easier though if you even still write code yourself. I don't think the productivity difference is that large.

Yes, that contributes to the "if it actually worked" sentiment.

It doesn't have to be slow, if the browser exposed C-like ABI for DOM access and web APIs like LocalStorage, the FileSystem API, ServiceWorker, etc - Rust bindings can be made and that boundary could be well optimised.

All we need is;

<script type="application/wasm" src="./main.wasm"></script>

The rest is just browser optimisations.

Still, it's fast enough that Rust frameworks can compete with the fastest JS frameworks on UI benchmarks [1]

Imo bundle size is a bigger issue.

[1] https://youtube.com/watch?v=4KtotxNAwME

From a software design standpoint, it certainly takes some adjustment going from OOP to the compositional architecture and structural trait system used by Rust, but it's not that big a shift.

The biggest downsides are the poor standard library that ships with Rust and the non prescriptive project structure which puts too much authority on the writer to figure out.

The biggest wins are that runtime exceptions and concurrency bugs are impossible. So you can basically write Rust with your eyes closed and, if it compiles, it's probably right.

Due to the high level of trust the compiler gives you, PR reviews (and reviewing AI generated code) is limited to design decisions and logic implementations.

I only really think about architectural decisions, like "this code belongs to X domain, so I should put it in X crate" or "my project should use a hexagonal architecture, does this change violate that? Should I create a package/crate to contain this logic?"

If you don't care about optimisations, a naive implementation in Rust will effortlessly outperform C# and use orders of magnitude less resources, but optionally, the pay off for optimisation is high.

Also, showing the weather is a great excuse to ask permissions for the user location.

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"? :)

Based on windows bloat Sally got fired because she was an old timer and cost to much so all the Sally's are gone and they're all Todd's now and windows is an unstable bloated mess.

The corporate dilemma between "I hired some less competent engineers and they're dragging the team down" and "I hired only highly capable engineers and now I have to give 10% of them bad reviews in stack ranking and later let them go"

Not to mention, they have 1 GB of headroom in their back pocket if/when they need to make Windows more efficient. Quick rewrite of that app or just scrap it and they've saved months of optimization.

Sally, obviously. Todd is much more likely to have a perfect haircut and immaculate fluency in corpotalk

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?

I think it's less about pie charts and more that weather apps can be very eyecandy-heavy. This sort of marketing works well for both consumers and board members.

[flagged]

Outlook, Teams, and other all show up as msedgewebview2.exe, so you also don't know which app is consuming gigs of memory doing nothing.

That is how apps work in 2016 onwards (the last decade).

Not the ones made with iced <3

I've been having _a lot of fun_ writing Go apps that don't allocate anything and that use small, preallocated buffers to stream through requests/etc. Basically TigerStyle for Go. I don't use arenas, I just size everything for the worst case (or make the sizes configurable at startup) and still end up using much less memory.

This is really only possible because I told Fable to build the underlying allocation-free HTTP, JSON, etc libraries and consequently I'm not building anything serious yet (although the libraries are well-tested using pre-existing corpuses from reputable projects e.g. curl as well as fuzz tested).

Most "outputs" are passed as out parameters for the function to fill in, and results are Rust-like enums (a Go tagged union containing only small data). I could also have returned (T, error) but I would have to take care that the thing I pushed into the error argument doesn't allocate--not sure if I made the right decision or not, but for now it feels nice. The worst part is that I don't really have a good way to communicate detailed error information, but that hasn't bitten me yet.

This has also been a lot less effort than writing Rust, although Rust would have real checks for lifetimes and im/mutable and enum exhaustiveness and so on--so far I haven't been bitten, and I suspect things like enum exhaustiveness can be addressed via linter if necessary.

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.

Instead of leaking memory it'll just clone the whole heap over and over.

If it's vibecoded, who GAF what language is used?

This argument applies regardless of how you feel about vibecoding. Lately people have been asking for x64 machine language and getting reasonable results.

I seriously do not think things could be any worse.

Reminds me of how they allow OEMs to install bloatware through Windows update now. I believe LG did something that leads to various app installs when you connect their monitors via HDMI.

ProgramBench was published recently where agents have to reconstruct a program given just the binary and documentation.

https://programbench.com/

But then we'd still be left with a C or C++ codebase.

Don't forget about R#

you jest but F# already does the ocamlness of Rust, no? and you don't need a borrow checker.

What a cursed comment haha

jdcasale you are right that Arc<RwLock<T>> is a code smell but I would take that a bit further that locking immutable data is even more of a smell. The real bad guy in this case is the RwLock not Arc. For anything that you hydrated once and never mutate you do not need the RwLock. Arc just clones the pointer so it is safe to share for concurrent reads so something like Arc<T> is fine and if you need initialization locking then LazyLock<Arc<T>> lets you lock the initialization but then everything else is just a pointer copy.

I hit this recently while building a url unfurl social card renderer for a project which ended up being something like LazyLock<Arc<Database>>

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

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)

yeah, locks are expensive.

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.

> 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?

If your goal is "delivering applications to only well-sighted people who can handle non-native and buggy UI", yes iced, EGUI, gpui exist. But as you can guess they are years behind Qt where you have quite the professional toolkit and properly implemented accessibility features (with a lot of bugs and horrible API because Qt).

The only foolproof way of having truly professional software is still the same: have N different, very-well integrated UI implementations (like Adobe does, $$$ in developer or agent fees) or use a Web browser aka Electron.

With Rust you can use Win32 or WinUI3. Both are provided by Microsoft-developed crate windows-rs.

EGUI.

Note: You ask different people, and they will all have their favorite tool kits. GPUI is very promising but new. There are a pile of others people will vouch for like Druid, Tauri (Electron-like but faster?) Slint (As the sibling poster pointed out), Iced, Qt bindings etc. I am not sure about native Windows etc bindings: I recognize that OS-native things like that are the most performant, but for me it's worth it to make my programs cross-platform and not worry about OS-specific things.

Note: EGUI is an immediate mode GUI, which isn't for all applications. But it has never limited me, and have written some complex UIs with integrated 3D etc.

Slint ?

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

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.

GPU programming?

I like Rust a lot but I'm not sure it would come very high up my list for web applications.

First compile. Every another will be significantly faster since compiler is incremental

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

Google announced that Android contains 5 million lines of Rust last year; sounds Tier-1 to me.

winui3, yes. but afaik windows-rs is the generic crate, right? not something ms released as rust-first approach to winui3?

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

Cold Fusion 1,000 mile gaze says hello

[dead]

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"

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 was meant as sarcasm, but judging by the downvotes, I clearly didn’t land it :)

Comment from every dang year.

The more recent complaints have been about Github being ruined by Microsoft. And this is why MS gets away with EEE, because people have short memories and say to themselves "nah, it won't happen again this time".

Then it happens. Again. And again.

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.

Correct. From the point of view of a stable desktop LTS system the code that the typical rust developer writes breaks within a few months as it starts using features from latest that are forwards compatible.