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...
It's abundantly clear that there is a strong headwind towards memory safety, whether that's Rust or GC'd languages.
nit: except in aviation
https://www.businessinsider.com/3-aircraft-fly-new-york-to-l...
C++ is still indicated for systems that are optimizing for performance and scalability characteristics, since it intrinsically requires a lot of "unsafe" constructs.
Meanwhile when I run tests on my JVM projects it can take 30 seconds just to start and the test execution is extremely slow too.
Even if you do manage to match the performance after warmup, you still have the issue that keeping the class files in RAM plus the JIT compilation state will cost more memory than simply running AOT compiled code. You simply cannot write processes that use a single digit MiB amount of memory on a JVM and getting down to 2 digits is theoretically possible but requires significant effort.
Once you get into the micro optimizations like the lack of mutable aliasing in Rust, there is significantly more potential for auto vectorization.
What you mean by "real world systems" is probably defined in such a narrow way that all the weaknesses of Java programs don't count anymore.
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.
Either that, or we really need to keep improving C and C++ safety story, if they are to stay around on those language runtimes, or compiler backends.
Btw, Rust ain't the only vector here. With an LLM at your side, you can also write your performance and safety critical parts in Lean and prove them correct.
Lean can compile to some pretty fast code. (Though it needs a bit more engineering work around eg SIMD to get really fast.)
unsafe {
mem::transmute::<&T, &mut T>(t) //takes a &T, returns a &mut T
}
To be clear, just declaring a block to be unsafe does not immediately do anything in Rust, it just allows a set of primitives that are not normally available, so it is possible to use unsafe judiciously without immediately stepping into a million landmines. You just have to be careful and ideally read the docs and the nomicon page for the operations you do, especially if they are very long.
It's harder to write unsafe code in Rust. That doesn't make it "unsafer". What I mean is this, if you want to write unsafe code in Rust the C++ way, your entire program has to have unsafe markers everywhere. It's just as unsafe as C++ at that point.
But if you want to write unsafe code in Rust the Rust way, you run into a requirement that didn't exist in C or C++: The abstraction around the unsafe code must be safe for you to drop the unsafe marker. This created a unique category of abstractions that no other language has, so if you are working on unsafe code in Rust you are often a pioneer doing something never done before.
The problem is that it actually sucks for dealing with the encapsulated parts. The reason everyone loves Rust is because they can just import a package where somebody else did the hard part for them and not worry their pretty little brains about a thing, getting high performance with minimal concern. That is a valid advantage, and that does make more mundane usage of the language safer. But it does not make the unsafe parts safer. There is every reason for having unsafe-oriented languages with ergonomics that actually make working with unsafe code more reliable too. The annoying thing about Rust is that 90% of its users are religious dogmatists who insist that Rust is the only valid language rather than accepting different languages can have different advantages, and moreover that 90% is basically the 90% who are benefitting from Rust while not being the ones who have to write unsafe code themselves.
(I have mixed feelings about that, but empirically it holds true.)
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.
LLMs are pretty bad at picking abstractions.
Sadly, agents don't mind generating gigatons of code instead of refactoring the abstractions.
One may get local maxima like an unsafe bonanza, or something that introduces a custom runtime memory management discipline at the cost of performance etc. Fully equivalent C++ to Rust in full generality is mainly wishful thinking. Of course that does not mean one should not try it.
See also my other comment.
I'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.
A disgruntled former Azure employee posting what a clusterfuck their SW, including their Rust effort is? That’s both rare and interesting.
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...
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.
> 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.
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"
Jai and... C3? FilC?
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.
Or something like SoftBound, from 2009,
https://llvm.org/pubs/2009-06-PLDI-SoftBound.pdf
It hasn't been for lack of choice.
[0] - https://learn.microsoft.com/en-us/cpp/c-runtime-library/debu...
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"
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.
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.
https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
Microsoft needs to choose for AOT Full Monty and leave the CLR behind.
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.
It looks like later, in December 2025, Rust was officially moved from experimental to official: https://lwn.net/Articles/1049831/
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.
Additionally we finally get some public news about the MSVC integration rumors regarding Rust.
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.
I checked just now. A recent Delphi with a project open: 175-200MB. Water (our IDE, I work at RemObjects) about 300MB.
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.
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).
And that 90% could be an underestimate here.
Anyway, even if that were true, rewrites are becoming drastically cheaper, simpler, and more correct with AI. The Bun rewrite is the largest experiment and seems to be 5-10x cheaper and completed ~100x faster and these costs are likely to come down further. So your claimed $1B rewrite today costs $100M and carries less risk. In 5 years it'll probably cost at most $10M and be finished drastically more quickly. And the vast majority of software doesn't cost $1B to translate.
Things that wouldn't be worth your time before are trivial these days with LLMs.
Grok immediately answered without a second thought.
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.
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.
For the same reason a Rust frontend is being developed for GCC.
Required some effort but we're happy with the result.
Calling Rust from C++ seems to be more technically straightforward than the reverse.
I'd be curious to know whether Rust developers believe Visual Studio is the right place for Microsoft to invest Rust specific coding capabilities.
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.
WSL is really nice, as is Windows Terminal. I particularly love its fonts (but that's probably just me).
The alternative being macOS, if Apple actually had competitive prices for all kinds of world economies.
If they can replicate that capability, I think it can be a draw.
I was a mac / Linux guy before my current gig, but Visual Studio is so much more capable than XCode that I basically only use the Windows machine except to debug mac-specific issues. Less so, now, admittedly, that the malware scanner process is literally always pegging a CPU core.
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.
Because of coding agents? :D
( Edit: I should probably inform the layperson: It was Visual Studio 2022 )
And for all we know, it might be officially supported in their internal builds of Visual Studio.
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.
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.
> Microsoft managed to add arbitrary code execution to Notepad.
> And it all points to a total disregard of the end-user
> This requires the Windows 11 operating system to be more conservative about RAM usage, Rust can be a part of that.
And little code can already have a big impact, e.g. react native in start menu coupled with edge running in the background
What legacy hardware was this?
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.)
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.
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.
I don’t have a problem with cars. But walking is still good for us.
Are you trying to be funny?
If I'd accidentally written a comment asking whether the intellectual skills I am losing are worth keeping, and make 2x spelling errors in a single short sentence, I'd find the unintended irony hilarious.
(but that's me, maybe you don't find accidental errors that you make to sometimes be funny)
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.
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 these days.
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 the productivity difference is that large.
Bit of a red flag if you really can't.
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 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#?
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.
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.
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.)
Sounds like unbounded, dynamic allocation to me!
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.
It seems like there's a newer build option to explicitly disable the "Fine location" permission prompt while still being able to scan for Bluetooth devices, but such beacons are somehow filtered from the list if it's enabled, and it's only available for builds targeting newer Android versions.
Sometimes the right API might not actually exist, but most of the time it's just lazy developers half-assing a port with no care for making the application behave appropriately for the platform. The prevalence of "Please don't turn off your computer while the game is saving" warnings is pretty clear proof that game devs in particular don't make any platform-specific adjustments they aren't forced to. (Game consoles usually require those warnings, but they're stupidly out of touch on a computer.)
But I could be misremembering. I haven't liked any of the recent macos releases. I will begrudgingly install Golden Gate to hopefully fix my m1 max 64gb slowing ot a crawl with Tahoe.
Between quick mod tools and even just the mods watch out nowadays. That vibe coded new game tool for a game you've played 10 years and never seen before could be just vibe coded malware slop, especially if its asking to sign software or bypass it. Now gamers are getting used to disabling security stuff just to play games.
I've never actually looked at this list, I've used lulu but they have a ton of security tools https://objective-see.org/tools.html
The forest job sounds nice :)
Oddly, I find the weather widget refreshes much more often than the app. I'll tap on the widget, which is up to date, which launches the weather app, which could be from yesterday, and have to wait while it refreshes. Apparently the app doesn't implement any background refresh at all, which is really weird.
I don't want to flex but that seems worth acknowledging from every perspective
Obviously, they should try harder, and this is an explanation rather than an excuse, but the graphics assets are mostly why.
Replaced by LLM and an offshore contractor. CaPiTaLiSm, right?
It is essentially an entire Chromium instance around msn.com/weather.
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.
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.
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.
Maybe this has changed since I wrote Rust, but that was a classic beginner fix. Just throw memory at it.
"Keep calm and call clone" is a good strategy for getting things working. Don't prematurely optimize code until you know it's the bottleneck.
The latter is usually what people who use the quote "premature optimisation is the root of all evil" think it means. Don't just keep calm and clone, consider what you're cloning and why, and then hopefully we won't end up with even more horribly slow software.
Such a slippery slope between “consideration of performance” and optimization.
> 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.
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?
.clone() on the other hand is indeed an easy/quick fix for a lot of issues you'd face when learning rust.
Sadly, other things a bit less so - the story for the thin battery-less stdlib + npm-style churn encourages bloat, and the semantics are obsessed with safety at a heavy cost to productivity unless you spam clone() and reference-counting - but then your program becomes slow, kind of negating the advantages, you might as well have written it in C# or something...
This argument applies regardless of how you feel about vibecoding. Lately people have been asking for x64 machine language and getting reasonable results.
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.
> 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!
Especially after the successful Bun 1.4 runtime migration to 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).
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).
- Embedded
- PC desktop applications
- Computationally-intense scientific programming. (Chem, structural bio etc)
- OSes, drivers etc
- High-performance tasks in general. CPU, GPU, etc.
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.
I hit this recently while building a url unfurl social card renderer for a project which ended up being something like LazyLock<Arc<Database>>
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).
- 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)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 ocaml had a cargo like experience, then I would migrate there.
I'd also argue that "runs on all OS" is true, but "is easy to develop without extra work in a cross-platform way" is not. I've never cloned a Rust project and had trouble building out of the box on Linux, but I'd estimate maybe one out of 20 C# projects I clone from Github build for me out of the box with `dotnet build`; the rest either require me manually tweaking the build configs to avoid stuff like hardcoded Windows-style paths or link to system dependencies that don't exist on Linux. I imagine you might argue that this is a property of how people use the language rather than the language itself, but that doesn't really matter from the standpoint of whether it's worth it for developers who don't use Windows to spend any time trying to invest in the ecosystem.
I'm interested in getting back to native application development; the job is on Electron right now and it's… meh.
* 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)
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
> 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.
I have no opinion regarding rust suitability as a game language, but your answer doesn't sound right.
The actual reason is much simpler. The industry is built on a handful of game engines. Those engines are extended or scripted in C++ or C#. Thus the vast, vast majority of the work force will only have experience with those languages and the entirety of game studios' tooling is built around those. The end.
This is a strong reason, but then why in other areas they consider it over C++ for greenfield but it hardly happens in games?
Someone in that industry can perhaps speak to it, but I have two cents of perspective...
I have helped a young person with gamedev interests try to learn rust (on Windows). They've learned some rust, but the graphics+Windows libraries and primitives to work with are not very good nor straightforward, even with AI assistance. Besides weakness in the gaming/rendering domain, there seemed to be some very real versioning/dependency hell that also didn't help.
It's massively easier to make progress on even just a 2D game with something like GDScript-based Godot (or Unity or...).
Indeed I got it wrong bc I translated from spanish and it seems to be a false friend. The word I meant is "malleable".
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;)
If you have to iterate a lot the shape of your code... no, it is not any good at this...
I don't know why you think it's only usable but this is your right.
Now 25 years later, MS runs its cloud businesses with Linux, and their development in Rust.
Yes.
May I see it?
No.
They use wordpress
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.
The type system and error handling ergonomics make it easier to write defect-free code than, say, Go or Java.
Simple servers are request scoped and mostly feature linear request handling, so you're writing simple vanilla Rust without the complex pointer semantics that you would use for systems programming. The async pieces aren't difficult either.
Serde-annotated structs are the best serialization/deserialization story anywhere. It integrates super ergonomically into Axum and Actix to make writing request handlers a breeze. They're super easy to read, too.
Compared to what? I see ASP.NET Core and Quarkus very competitive. The virtual threads in Java are great, paired with structured concurrency IMHO.
If I have to go microservice or API, I would choose FastAPI for fastest delivery and if I have to rewrite, Go, unless it is massive scale and scaling horizontally becomes a headache I would not consider Rust/C++ for this.
All the backend, etc. for the company I have been working for is C++ for the fast parts but all tools around are Python (with NiceGUI and Flask mostly).
I think the combination is quite powerful, btw.
Also the use of italics there is rather jarring.
windows-rs
What’s a Tier 1 language?
Consider what that means: Tier 1 represents roughly the top 0.001% of languages. Pauci sed electi - few, but chosen. The crème de la crème. The aristocracy of languages. Primus inter pares, yet standing at the very edge of what programming language greatness can be.
Ad astra per aspera. Through hardship, to the stars. Tier 1 is not merely another rank: it is the ultima Thule, the farthest frontier, the crown, the apotheosis.
This “Tier-1 language” engineering status for Rust means giving internal teams a paved path from local development to production: secure toolchain builds, productive developer tooling, quality workflows, deep platform integration, and compliance with the SDL requirements Microsoft software must meet.
Python for windows application development never really got there and is kind of a technically runs if you want to run python kind of situation.
Seems pretty good to me ;)
(I know you're joking).
how can one claim it is tier-1?
Also random student, nothing official from Microsoft.
The project linked above has been posted to HN in the past a few times though.
The year was 2002, VB6 had just been retired for VB.NET which had 0 backward compatibility.
And then we all became Flash/AS3 developers.
The End
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.
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.
All breaking changesin rust done via editions and you can mix-and-match editions.
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.
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.