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.

I know it's silly.

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.

    Embrace.

    Extend.     <-- You are here.

    Extinguish.

The project linked above has been posted to HN in the past a few times though.

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

Yes.

May I see it?

No.

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

They use wordpress

Also the use of italics there is rather jarring.

What’s a Tier 1 language?

Also worth noting that an event loop by itself doesn't give you serialization by itself, it can just allow you to gain concurrency without parallelism. You still need some form of serialization by way of something like actors (or async locks).

If you have to iterate a lot the shape of your code... no, it is not any good at this...

The type system and error handling ergonomics make it easier to write defect-free code than, say, Go or Java.

Simple servers are request scoped and mostly feature linear request handling, so you're writing simple vanilla Rust without the complex pointer semantics that you would use for systems programming. The async pieces aren't difficult either.

Serde-annotated structs are the best serialization/deserialization story anywhere. It integrates super ergonomically into Axum and Actix to make writing request handlers a breeze. They're super easy to read, too.

> People did this a lot when rust was not as popular but there are plenty of very good rust programmers now who understand the language and can make programs that are significantly more performance for a marginal development cost.

Why isn't the game industry moving to it then? Bc it just cannot compete at volubility with C++, among other things. Yes, you can have skilled people, but the borrow checker is still there and that is an anti-change-me-fast fact of life. I think things like sending batches of info to the GPU in casted ways, alignment, etc. all go against safety naturally but this is fundamentally what needs to be done anyway when transfering data to the GPU, so adding a layer of safety for the sake of doing it to notice that your data-oriented pipeline has to suddenly change its shape would mean repeating work...

Namely, Rust is just not good at this. Rust is good if you can replicate a safe layer that is very reusable every time (when interacting with unsafe) or when you do not need unsafe at all or hardly, where you can take advantage of its safety fully.

Also, there are certain very tweaked data structures such as Boost.MultiIndex or linked lists with intrusive hooks and others that are not easy at all in Rust and they do have value in some situations. I had some of this in some telecommunication systems before.

It notably doesn't have any plugins relevant in this scripting context. It only has themes/language syntax/servers, nothing about actual editing

One way is sure the native language + embedded scripting language combo but that's got the trap of impedance mismatch i.e. you spend all your time making engine not game then it overruns. But in any case having a way to iterate fast is a hidden productivity superpower, look at how many game studios have Live++ licences on their webpage;)

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

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

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

LLMs are pretty bad at picking abstractions.

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.

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.

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.

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.

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.

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

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

And that 90% could be an underestimate here.

After the Longhorn reboot all the .NET based APIs were remade in COM, while WinRT introduced in Windows 8, adds a new base interface, replaces type libraries with .NET metadata, and requires an application identity.

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

Bethesda is not a very good counter-example, in my opinion, because they regularly** break mod support. I don't know enough about how these mods work to be sure, but given that the 32-bit to 64-bit transition was one such major breaking event, I am suspicious that they are not actually effectively sandboxed. I also don't play many Paradox games (and the one I did play a lot of, Cities Skylines, is a special case, and also a Unity/C# game), so I don't know how they do things.

The best example I know of for strong, sandboxed, first-party mod support would be Factorio and its Lua mods. However, these mods are constrained to doing only those things the game developers anticipate and want to allow, which means every mod for Factorio produces a very Factorio-flavored experience, though AFAIK there are some extension points in the API which are only really used by mods (or were, at least, before the Space Age expansion).

The biggest downside of C# (and Java) mods is indeed security, but the biggest upside is that a lot of games can add modding support without too much extra work. Such extra work is often not possible (they don't own the engine) or unlikely to happen (they don't have the time/budget), outside of special cases.

* = Whatever else you might think of Nexus Mods and its policies and drama, they generally take malware seriously

** = Roughly every 3-4 years, which means it's happened like 4 times with Skyrim, and one of those was so major that it completely split the mod ecosystem

I don’t think it’s a good policy in general. Mostly I think it would just end up in alienation and people not wanting to work with you. And Martin did leave. But he had a point and it seemed to get resolved.

I don’t have a problem with cars. But walking is still good for us.

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

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

It seems suspect to me is all; the repayment time on $1B from a rewrite of an existing software stack isn't generally huge unless it also enabled adding new features that weren't possible before which enabled significant new revenue streams that justify that $1B outlay.

nit: except in aviation

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.

Regardless of how evil gigantic companies can be, or what the ideal world should look like: from a pure usability perspective, windows is top of the list.

If I got 5$ every time a linux/mac enthousiasts has to tell me they just cannot run something, and proposing a myriad of workarounds to stick to their ideology, I could buy an apple vision pro and let it collect dust in the corner of my basement.

The alternative being macOS, if Apple actually had competitive prices for all kinds of world economies.

The point of these low/zero overhead languages like Rust is you're in an environment where memory management is ultra critical. The dotnet garbage collector does more than a good enough job for a weather app, likely a much better one than vibe coded .clone() Rust

Instead of oscillating between Rust and 1 GB webview apps just ... use the excellent managed language that exists on the operating system appropriate for GUI applications?

"Keep calm and call clone" is a good strategy for getting things working. Don't prematurely optimize code until you know it's the bottleneck.

> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

Notice the aspects and the reasons for knuth's "premature optimization". Is it making the code harder to debug and read? Is it a non-critical path?

If an optimization doesn't impact readability or debugability (for example, picking a datastructure that fits the problem instead of just using a List for everything). Then you should do it.

I see the quote so often pulled by people that want to justify inserting a n^2 algorithm when a log(n) solution is either the same amount of code or 1 line extra.

There's also important context about the era knuth was programming in. Optimization in the era of knuth was targeting the hardware and tickling things like the CPU cache and memory in a very specific way. It was things like clever bit manipulation and packing to save memory. That's the context. In modern terms it'd be "don't use SIMD intrinsics until you know you need them". It wouldn't be "Don't think about algorithmic complexity" which is where I most often see that kludge deployed.

I think this used to be true more than it is now. Memory has been relatively expensive in cloud environments for a while (often 2x the price of an ec2 node for an equivalent with 2x RAM) and DRAM shortages aren't helping.

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.

I don't want to flex but that seems worth acknowledging from every perspective