Rust is tier-1 language at Microsoft | Hacker News Reader

Rust is tier-1 language at Microsoft

rustfoundation.org

730 pointsmmastrac517 comments

Those interested in this may find the following articles of interest:

Microsoft goals [edit: err, Microsoft hiring manager vision-casting goal ] 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".

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.

No, after this made some waves he or some other senior (I don't remember exactly) reported that this is not an official plan.

what's your point?

Why are you saying that you love Hitler[1]?

(that isn't what you said? what's your point?)

[1] https://en.wikipedia.org/wiki/Godwin%27s_law

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

> A headwind makes it harder to advance in the direction you're going

nit: except in aviation

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.

In real world systems, Java can beat programs in compiled languages like C++ and Rust when it comes to throughput and even latency.

> C++ is still indicated for systems that are optimizing for performance

The only evidence I've seen for this is that people with a vested interest in my believing this keep saying it is true. That's the exact same evidence I have for Trump having triumphed in Iran. Do better if you want me to believe you.

> since it intrinsically requires a lot of "unsafe" constructs.

This is an excellent reason to choose Rust. The whole point of Rust's technology is to enable you to encapsulate the tricky difficult part of the problem so that people don't blow their foot off working on the mundane parts of the software. And the truth is there are always mundane parts of the software.

I'm feeling generous so I'll add more here: Vec<T> illustrates how this works. This is a growable array type, C++ has std::vector<T> for much the same concept. But inside Vec<T> this encapsulation is used heavily so that there's a RawVec<T>, which doesn't care about knowing how many things are in the growable array, only about its capacity, then a RawVecInner which doesn't even care what things we're keeping in the array, it's just an appropriately large container for whatever it is, that RawVec<T> remembers what T is if that becomes important - and then a Cap which doesn't even contain things, it's just in charge of being able to represent the capacity correctly while having the same shape as "just" an integer but not always necessarily working like one.

Vec<T> is entirely safe to use, very pleasant, no danger. But internally it's extremely sophisticated, hence the layers of different types encapsulating different pieces of the problem to make a growable array type with excellent performance.

There is no way they can re-write everything in Rust by 2030. No way. Even new projects are modern C++ at MSFT. Some teams are creating their Rust/C++ binding but that's a very small fraction.

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

What with this llms not so good in rust mantra? Something changed? In my experience they are pretty good, but haters gonna hate.

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

Yes, I found these agents to be better at producing acceptable Rust than at producing acceptable Python code.

In addition to the Rust compiler, you can also tell them to make clippy happy. Both in normal mode or if you are feeling nitpicky, you can also tell them to make clippy::pedantic happy.

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.

To add to this, I find that the delta between the amount of code and pain you get with good and bad abstractions is substantially higher in rust than other languages. It's alright to muddle through in Python or TS, but with Rust bad abstractions are punishing.

LLMs are pretty bad at picking abstractions.

These kinds of sanitized corporate, feel-good articles are anything but interesting.

A disgruntled former Azure employee posting what a clusterfuck their SW, including their Rust effort is? That’s both rare and interesting.

Just in case slop is not strong enough.

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.

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

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.

Rust is already used in production for embedded (although only here and there). Not all places are ready, but I don't believe it's a decade away anymore.

All reasonable pain points. On the "Cargo fuckery" though, you might consider switching to an alternate build system like Bazel. Comes with its own set of issues (rustc isn't tied to Cargo, but the third party ecosystem definitely assumes it). But for embedded where you're cross compiling and working with C and C++ as well, I find it's a better solution than Cargo.

I'm in the same boat. Using Rust within Yocto is tricky since the whole point of Yocto is that you have a system which can build reproducible images. I can't have Cargo going out and fetching crates during the build process, they need to be recipes and artifacts which are accurately versioned and identified.

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

What "space"? My guess: HFT or HPC.

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.

If you want to imagine a "1.0 quality" which means "Is used in some software that isn't a toy" then all kinda of crap counts. Bill has given specific goals, I don't think he'll meet them or perhaps even understands how high those bars are†, but even by his understanding Odin hasn't reached those goals.

Unlike Jai you can just download Odin and see for yourself, it has the particular things Bill prioritized (swizzling, a very particular way to do generic programming) and it doesn't have things which Bill feels are a mistake (most obviously package management, but also closures, first class user-defined types, macros, I could go on). The resulting perf isn't very good, and to me it "feels" clumsy to use.

One of the striking things in the Handmade languages is that they're so often wedded to LLVM and so in that respect they're much worse than C which of course isn't even wedded to modern architectural choices like 8-bit bytes, much less LLVM. Zig is the most free of this peculiar curse, which is ironic because years ago Bill called out Zig as unable to escape this, while insisting Odin would not require LLVM - the reverse of what actually transpired.

† In particular Bill thinks he's going to completely specify the language. Anyone who works on this problem for WG14 (C), WG21 (C++) or Rust knows that's basically a rabbit hole made entirely of more rabbit holes. I think Oracle's Java has a complete specification, and maybe TC39 has one for "Javascript" neither of those were uh, cheap or easy.

Zig too. But this is far from being mainstream. Rust took around 5 years I think to become accepted in major companies, and those languages are harder to justify.

> other two famous Handmade languages

Jai and... C3? FilC?

Jai and C3. I do not consider FilC to be a distinct programming language. AIUI the C I wrote twenty years ago would work with Filip's approach, maybe it needs minor tweaks in a few cases (mmap stunts for example) but likely not for much of what I wrote.

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

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.

I'm personally a big fan of garbage collected languages. It's just unfortunate that Microsoft chose C# not to be Ahead-of-Time (AOT) compiled but running on a virtual machine like Java (after which it was modeled after).

Alas, that ship has sailed and Rust has many interesting features so I'm comfy with it taking over the role of C/C++ over the next decades.

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

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

Some deployments can be AOT compiled (ASP.NET, mobile), others (like WinForms, WPF) cannot. That makes it confusing and fickle since not all language features work with AOT.

Microsoft needs to choose for AOT Full Monty and leave the CLR behind.

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

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

Why, when they have Swift for that role?

Rust is a serious contender for the next mainstream, widely adopted low level language.

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

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

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.

Where did you hear that it got pushed back out? It's going strong as far as I can tell.

I expect that using Rust is in some years just the sign for vibe coded shit that only doesn't crashes every two minutes because the compiler is stopping the AI from doing the really dumb things.

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

I bet you never heard of Microsoft. Fast, they don't move. But boy, are they slow at fixing bugs.

I was making the same argument just a moment before, using TIOBE. Now TIOBE is awful, but Rust is at rank #10 right now. I think this settles the older discussion as to whether Rust will prevail or not.

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.

Get back to me when Rust has a stable ABI and can produce dynamically linked binaries.

Rust supports opting into the C ABI

So does any other language which wants to be useful; being able to call C functions is table stakes for a systems programming language. But Rust itself can still only generate static binaries, because Rust doesn’t have a stable ABI.

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.

I'm totally disgusted that my Visual Studio 2022 instance uses 2 Gigabytes (!!) of RAM to run. What the hell is it doing that it's using that kind of memory?

How about those morons solving that first before moving towards Rust. An IDE shouldn't have to use more than a 100MB of RAM tops. Anything more is inexcusable or needs a detailed explanation.

BTW Firefox uses 1.1GB RAM so it's not immune from criticism either.

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

You're right, though I'm not sure about all modern software quite to that extent. VS does have a reputation for being bloated. Even startup is not super fast IMO.

I checked just now. A recent Delphi with a project open: 175-200MB. Water (our IDE, I work at RemObjects) about 300MB.

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.

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.

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

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

I'd say you only pay 10% of the cost when you finish/launch the re-written software. The other 90% of cost comes later in the format of operations, deprecation and migration, people both users and devs, community friction and learning cost.

And that 90% could be an underestimate here.

Real numbers. I can't say what directly, but you can make a good guess if you read my comment history. (I don't think this would be worth your time, but you could)

Rewrite it in Rust has always been more a fantasy of the C++ community than a goal of the Rust ecosystem.

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

The big news here is they've replaced LLVM with MSVC's backend.

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

Eh, they call TypeScript a tier 1 language too.

MSVC always was the default backend for Windows platforms.

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

... but why? The MSVC backend has been falling far behind LLVM with every release. I understand they want uniformity but IMHO either they catch up or they switch fully to LLVM, if they can

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.

What are these things?

This makes strategic sense in multiple ways:

1. Rust's memory safety design will help Microsoft improve a gigantic portfolios of products that have been known to have lots of CVEs and 70% of them are memory safety issues, according to Azure CTO Mark Russinovich's talk at RustCon last year.[1]

2. Windows 11's forceful push to retire millions of legacy PC hardware by putting Windows 10 EOL last October was absurd for millions of consumers and businesses. I was literrally helping a S&B having to replace the entire fleet of working PCs simply because Windows 10 of EOL and Windows 11 refused to run on those legacy hardware. Quite honestly those PCs ran just fine! That's why some has been migrated to Linux, in particular to Google's ChromeOS Flex.[2]

3. RAM shortage due to AI boom exhausted the memory chip manufacturers' production pipepline for at least the next 5 years. This means the mainstream PCs sold today will actually have a diminishing RAM size configurations than last year's in order for the PC manufacturers to not drastically raise the product price (or raise prices drastically for high RAM configurations like Apple does). This requires the Windows 11 operating system to be more conservative about RAM usage, Rust can be a part of that.

[1] https://www.youtube.com/watch?v=uDtMuS7BExE

[2] https://chromeos.google/products/chromeos-flex/

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.

    > Microsoft managed to add arbitrary code execution to Notepad.

You write as though this was an intentional feature. Not, it was a CVE. I had to Google about it. For anyone else who didn't know about this CVE: "Microsoft added Markdown (.md) support and interactive hyperlink parsing to the modern Windows 11 version of Notepad. Improper validation of links meant that clicking a crafted hyperlink inside a Markdown file could cause Notepad to launch unverified protocol handlers without proper warnings." This CVE has already been patched.

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

I don't understand this part. Are you trying to say that because they had a security flaw in a new feature that this demonstrates "total disregard of the end-user"? It seems like quite a reach.

Arbitrary code execution in Notepad. That’s just insane, regardless of how they added as a “feature”.

At least 67% of your comment has nothing to do with this article.

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

    > This requires the Windows 11 operating system to be more conservative about RAM usage, Rust can be a part of that.

Most of Windows is written in C and C++. How would Rust help to reduce RAM usage?

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

The best estimate that I could find says that Win11 is at least 85% C and C++. Where did you get your 50% value? Or do I misunderstand your comment?

How does Rust help with 2 at all? IIUC the main requirements were not memory or performance related but TPM and instruction set minimums.

> Windows 11 refused to run on those legacy hardware

What legacy hardware was this?

What’s the story for Rust-C++ interoperability these days? That’s what kills adoption. Most C++ devs I know like the idea of Rust, but no one is going to go rewrite 30 years of working code. It needs to be something you can incorporate gradually.

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.

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

You might want to take a look at https://github.com/hkalbasi/zngur

Calling Rust from C++ seems to be more technically straightforward than the reverse.

What we do at work is defined a clear boundary and use extern "C" functions in Rust to make them callable from C++, and the same for callbacks.

Required some effort but we're happy with the result.

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

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.

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

Hot code reloading, and incremental linking would be great, given the build times.

> 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

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 )

Microsoft doesn’t use Visual Studio internally for many of its products such as Windows.

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

Windows is built using BuildXL, a very different build system from MSbuild used in Visual Studio: https://github.com/microsoft/BuildXL/blob/main/Documentation...

> BuildXL has also been proven to scale to large codebases (e.g., Windows/Office repositories) where builds can consist of millions of processes with terabytes of outputs

BuildXL is also NOT compatible with VS and they have no plans to make it so. from the readme in the repo: https://github.com/microsoft/BuildXL

> There are currently no plans to integrate it into Visual Studio.

in Windows, some teams/people use it others don't. Historically it hasn't worked well with some of the internal build/test/etc stuff, that's mostly changed in recent years.

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

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.

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

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!

So when will we get tier 1 debugging support in Visual Studio?

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

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.

> even before LLMs could spot my bugs in an instant

I guess it depends on the bugs.

LLMs even INSIDE the (VS) debugger couldn't work out some of the more recent bugs I have been looking at. Never mind by statically looking at the code base.

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.

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.

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.

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

Works already in Visual Studio Code, even seamlessly between C++ and Rust

RustRover, my friend.

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

I've been using it since ~23 without any issues, the ui's have all been similar to Borland's stuff since the beginning.

u dont debug rust mate if it compiles it works

I've been writing Rust professionally for the last 5 years (where my first decade of professional experience started in frontend, then moved down the stack TypeScript/Node, Go, C# and so on).

From the perspective of high level application development, I can't see a technical use case for a language other than Rust these days. If wasm worked (and MacOS/Windows/Android/iOS native UI support existed), I would write my backends and frontends exclusively in Rust.

From a low level programming perspective, the high performance of Rust combined with the self-describing type system makes it very ergonomic to use (trying to figure out how a C function signature translates to behavior is a frustrating experience for me).

The thing I have been most saddened about is the lack of professional opportunities for Rust, particularly in Sydney (where I live). I considered moving to the US for the higher salaries and access to Rust roles but recently landed a role here.

> From the perspective of high level application development, I can't see a technical use case for a language other than Rust.

Bit of a red flag if you really can't.

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.

This is giving real "if all you have is a hammer" vibes.

I also have years of experience with Rust, but I moved off Rust a few years back simply because I'm sick of the anemic stdlib and lack of mature ecosystem around anything even one inch off the beaten path. Cargo is a shitshow and Rust forces you into an npm-like experience for a whole bunch of functionality that ought to be included in the box. You're juggling libraries with versions like 0.1.2 of which there's seven, none of which are feature complete and five of which are semi abandoned. Then you run into the orphan rule trying to fix or extend any of them.

I kind of think some other language will come along, take the borrow checker, take all the type conveniences that Rust stole from OCaml that make Rust so nice, glue it all to a Python/Go/dotnet style fat stdlib, complete with an optional GC for all the things that don't actually need bare metal performance (just stick an arena in stdlib), and Rust will feel like a clunker by comparison.

    > From the perspective of high level application development, I can't see a technical use case for a language other than Rust these days.

What is wrong with C# and WinForms/WPF? It is an excellent platform to write enterprise desktop apps. Also, developer efficiency is way higher in C# compared to Rust. The language is much simpler, and the VM supports garbage collection. Again: For enterprise apps this is a big win.

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.

If wasm worked is a pretty big caveat still. DOM APIs are still significantly slower in rust using wasm than pure js last I checked.

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;

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

Interesting perspective. I toyed with rust a bit from the perspective of a c# background (and a bit of java, php, classic asp, JavaScript, typescript, etc) .

I like rust, but I've come to still prefer c#'s object oriented features. Perhaps it's my naivety, but I've found c# AOT compilation to do plenty of trimming and startup performance optimization that I don't see it as a bad option.

Have you made a personal comparison on Rust vs Object Oriented Languages like c#?

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.

We've seen several anecdotes where JIT languages (e.g. Java) outperform Rust in throughput and latency in long-running server programs.

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.

edit: Oh, my "fix" for most of this is fakegps and mocking my android systemwide gps location to whatever, if you go through this.

What does that have to do with its RAM consumption, though?

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.

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.

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

The problem is the Webview2 prevalence, and note many Rust projects love their webviews as well.

Not the ones made with iced <3

Yeah, however there are probably much more using Tauri.

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.

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.

> This has also been a lot less effort than writing Rust

I have never written such Go, but as an experienced Rust programmer I can tell you Rust is not hard to write after learning it. Learning it can take more time than usual (although there is also contrary evidence, e.g. from Google) but after you're used to it, you're basically as proficient as in other languages, except some glitches (that can be expensive - rewriting your main structure, but are fortunately rare). Considering the effort involved in coding in such unnatural Go variant, I tend to believe it is far easier to code in Rust (including coding in Rust using this style, since it is more suited to it).

Of course, if you're just vibe coding everything, maybe it is easier because maybe the LLMs write such Go better that they write Rust. But if you're not, even if you're only reviewing the code, I believe it's easier to review Rust code than to review such Go code (and potentially than reviewing any Go code, but that is a different matter).

Have you considered doing this in OCaml?

You'd get most of the benefits of Go and Rust.

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.

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.

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

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.

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

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.

I can't comprehend why 250 MB for a weather app on macOS is considered normal.

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

And that the calculator does not take 5 seconds to load

are they launching for the graphics in the background the whole MS Office and PowerPoint?

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.

Conversion of legacy nontrivial C++ code bases into Rust (or anything else for that matter) feels like it should be one of the "Millenium problems" for AGI. That and full self driving - including the nuances of gesturing to a human about who's going to reverse in a single lane in a snowstorm.

But if 50% of code can be converted automatically to safe idiomatic Rust? Great. Doesn't sound too far fetched. But yes, there's certainly a long tail here.

> Conversion of legacy nontrivial C++ code bases into Rust (or anything else for that matter) feels like it should be one of the "Millenium problems" for AGI.

Whilst I have no doubt that LLMs will be useful here, I still have reservations about validation. I think experience tells us that test coverage is generally insufficient to ensure functional equivalence, and not all components are well specified.

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

https://programbench.com/

If we have AGI, it can just solve all the memory issues in the existing codebase instead of rewriting it all.

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

Given the hypothetical presupposes AGI, so what? We wouldn't be the ones reading or maintaining it.

It’s cool to see rust join C++, C#, and typescript as primary engineering languages. Confusingly there are no tier 2 or 3 languages, just tier 1 at Microsoft

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

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.

What a cursed comment haha

I guess we should watch for contributions to Servo

The best C++ interop is just writing C++. Anything else is just wasting time and energy.

I haven't made a full switch yet, at this point I'm experimenting more heavily in Rust.

First I built a wrapper for a very simple text editor based on KDEs KTextEditor (basically bindings around Qt C++) then a wasm wrapper around Canvas/WebGL for a basic 2d display list that currently supports sprites and gradient masking.

So far I've been getting away with it just as pure vibe code.

However, the bulk of my primary application is written in Typescript (both client, server and workers). I watched a recent podcast with Anders Hejlsberg (creator of C# and Typescript) where he made a strong argument for why they chose Go over Rust for the updated Typescript compiler. Due to similarities between Typescript and Go, partially based around them both being GC languages, it was just a better fit for a port.

So I am on the fence a bit here but still leaning towards Rust. I'm going to see how far I can push my two personal experiments. I'd really like to get the significant majority of the code I write into two languages (Typescript for anything web-ish and Rust for everything server-ish).

As much as I like Rust. Still sad that F# didn't get this much support from their own mother.

A MSVC-backend? At this time of year! At this time of day! In this part of the country! Localized entirely within Microsoft?!?

Yes.

May I see it?

No.

But which GUI toolkit will they use for all their new rust applications?

WinUI (3) via Windows Reactor

I don't know why I feel the entire software world is going to switch to Rust (more than the others), C++, and Assembly soon.

Especially after the successful Bun 1.4 runtime migration to Rust.

Visual Rust sounds like a defect but I'm looking forward to it.

In my time in VC++ and .NET teams, there was only one 1st tier language at MS. It was the one that existed to be whatever Windows wanted - VC++. I've not been there for about 10 years but I haven't heard that anything changed and the blog pretty much confirms that sentiment.

My advice to the Rust team: you're going to get shoved so I hope you're good at shoving back. At least you don't have to worry about stevesi (unless you're with a16z or have kids).

What other langs do they consider tier 1? What’s in tier 2?

With certain rough edges like complex traits and Async aside, rust is an S-tier lang in several domains. Of interest:

  - Embedded
  - PC desktop applications
  - Computationally-intense scientific programming. (Chem, structural bio etc)
  - OSes, drivers etc
  - High-performance tasks in general. CPU, GPU, etc.

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.

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.

All those applications area sensitive to asynchronous programming.

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.

Microsoft is a tier-0 company.

It’s interesting how things have changed in 25 years. Around 2001, Microsoft was crusading against open source and facing an antitrust lawsuit with Netscape.

Now 25 years later, MS runs its cloud businesses with Linux, and their development in Rust.

That grin will soon be wiped off their faces when Linux Mint takes over the desktop and wipes another one or two Trillion dollars off their market cap.

They've changed business model from selling software (windows, office, terminal server) to selling services (cloud services, user surveillance/exfil, advertising). The OS is just a vehicle to drive those service streams: maybe it's even a loss leader?

New CEOs can do that to a company.

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

I think there is no way that they recode everything in Rust in the next xears. As far as I know, it's inside Microsoft just a PoC for the moment.

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

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

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.

What is wrong with wordpress exactly?

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.

So, Rust.NET?

VisualRust.NET Copilot

Just to clarify, are they 'using' it, or are they 'embracing' it?

We don't learn Rust at school at all(both undergratuate and gratuate student)

If I were the Rust foundation I'd be keeping this to myself right now.

Why?

So do we observe overall Microsoft software quality improvement so far?

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.

NT kernel rewrite when?

I'm wondering how they deal with long compilation times

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.

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.

this is fantastic news but it being rustc_codegen_utc and not rustc_codegen_msvc really threw me

It is a decompiled language.

started learning rust using the rust programming language book last month!

ermm... which are the rust-native libs which enable winrt3.0 native apps?

Do you mean winui3?

windows-rs

i've never seen such a damning indictment of a language.

… and they proved you can still write tier-10 software with it

LOL!

How the open source turn tables have open source turned

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

I never hated a programming language grammar until I saw Rust's. I understand the technical advantages; I still hate it.

I know it's silly.

This thread deserves a meme

who cares. AI will translate brain waves to binary within 5 years.

apparently hackernews devs don’t like this

Rust is now in the Top Ten of TIOBE. Now, TIOBE sucks, but I found that as a general trend plotted over years, it is not that bad. So Rust is definitely having solid demonstrated use cases in the "real" world.

Now their broken slop code is at least memory safe.

VisualRust#

Waiting for the deluge of Rust cultists....

Congrats to the folks involved!

Having previously led Rust at Google, I remember several great cross-company discussions with Microsoft engineers on interop.

Companies with massive C++ codebases use Rust as a pragmatic hedge. C++ as we know it is unlikely to ever become fully memory safe, and unlike C++ standard committee voices who dispute the urgency, major industry players need actionable solutions today.

Because these existing codebases are so vast, Rust must have a viable C++ interop story. However, defining what "good interop" means remains tricky. C++ routinely tolerates aliasing and relies on patterns that violate Rust's aliasing rules. Shared backend infrastructure (like connecting rustc directly to MSVC backends) helps with ABI layout, cross-language inlining, and toolchain parity, but it doesn't solve the core type system divergence.

The fundamental obstacle is type systems:

* Boundaries remain unsafe: Compilers cannot statically verify C++ safety invariants. Crossing the boundary stays in unsafe territory.

* Idiomatic C++ structures often cannot map cleanly into Rust idioms. This forces developers into onerous safety comments or heavy wrapper layers. At some point, application writers will consider serialization / in-process RPC or a full rewrite as a cheaper or cleaner option of getting interop.

Bridging this gap on the ABI level is pragmatic, but pushing Rust's semantics to accommodate C++ edge cases risks compromising "pure Rust" goals. I doubt the broader Rust community will favor complicating Rust's safety model just to smooth over legacy C++ patterns.

To be clear: practical interop is a worthwhile investment, but "seamless interop" needs serious qualification. It will always have hard limits. There will always be friction at the boundary and it will always be a tough sell.

Yet another good reason for me to steer clear of the language.

crazy i like that

Sephora is tier-1 at the Clown convention

Good, C# is one of the worst languages there is, hopefully they turn it in to tier 18

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.

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.

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.

    Embrace.

    Extend.     <-- You are here.

    Extinguish.

We may never actually reach Extinguish. That won't be by Microsoft's choice, though.

Comment from 2007.

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.

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.

Reply on news.ycombinator.com