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...
That is not "Microsoft goals", that is "one employee's LinkedIn comment of his personal goal".
mkehrt 16 hours ago [-]
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.
afdbcreid 15 hours ago [-]
No, after this made some waves he or some other senior (I don't remember exactly) reported that this is not an official plan.
mkehrt 11 hours ago [-]
Sorry, by "official support" I mean that there is support within MSR to investigate these tools as a research project, no that there is a plan to actually do the conversion.
andsoitis 9 hours ago [-]
what's your point?
eterm 18 hours ago [-]
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.
estebank 18 hours ago [-]
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".
eterm 18 hours ago [-]
You're right, I better do a 360 on my comment ;)
foolswisdom 17 hours ago [-]
A 180 might be more useful :)
andsoitis 9 hours ago [-]
oh boy, maybe geometry intuitions and spatial reasoning are what's really needed.
tigerlily 8 hours ago [-]
Or maybe a nice sabbatical aboard a sailboat expedition.
imp0cat 6 hours ago [-]
Or maybe not, because that's where confusing 180 and 360 degrees or headwind and tailwing will REALLY bite you.
lazyasciiart 1 hours ago [-]
Sure, but if you come back, you'll have really learned that stuff!
shermantanktop 6 hours ago [-]
Do it twice to be sure
spacechild1 4 hours ago [-]
That was obviously a joke...
odo1242 14 hours ago [-]
> A headwind makes it harder to advance in the direction you're going
nit: except in aviation
delta_p_delta_x 13 hours ago [-]
Also in aviation, but with caveats; you want to take off and land with a headwind, because the headwind gives a greater airspeed which means greater lift.
aaronmdjones 8 hours ago [-]
This is true for takeoffs but not for landings. You want to land with a headwind because this means that for the same airspeed you have a lower groundspeed, i.e. when you actually touch down you're going slower on the runway than if you touched down at the same airspeed but with a tailwind.
peterfirefly 2 hours ago [-]
In other words, it's because of the greater lift.
odo1242 11 hours ago [-]
Ah
wood_spirit 5 hours ago [-]
Surely a headwind makes an aircraft travel slower over the ground so it takes longer to reach the destination?
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.
za3faran 4 hours ago [-]
In real world systems, Java can beat programs in compiled languages like C++ and Rust when it comes to throughput and even latency.
imtringued 3 hours ago [-]
This is so untrue I still don't know how anyone can even claim this. When I run tests in Rust, the biggest portion of the time is spent compiling the test (lets say 3-4 seconds), then the tests conclude practically instantly, in less than half a second.
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.
xienze 18 minutes ago [-]
> This is so untrue I still don't know how anyone can even claim this.
Because it's referring to long running processes, AKA the kind of things where hot paths can be JITted into faster native code than is possible from static compilation because the JIT has information about the real-world usage patterns.
> Meanwhile when I run tests on my JVM projects it can take 30 seconds just to start
That strongly implies you're using some sort of framework that's doing a _lot_ of initialization. That's not JVM startup time, don't be intellectually dishonest here.
> 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.
Again, the main use case for Java is long running server processes. No one cares if the binary is 1, 10, or 100MB or if it consumes 2, 3, or 4x the memory as long as the throughput is there. And Java has a long track record of delivering very good performance in those contexts, coupled with an extremely rich and mature library/tooling ecosystem.
captainbland 48 seconds ago [-]
> or if it consumes 2, 3, or 4x the memory
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.
tialaramex 12 hours ago [-]
> 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.
eru 9 hours ago [-]
Tangent: your comment would have been stronger without the politics.
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.)
2 hours ago [-]
pjmlp 2 hours ago [-]
I do think though, it is in the best interests for all compiled languages to eventually bootstrap themselves, instead of depending on either C or C++ for their implementation.
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.
vrighter 5 hours ago [-]
I heard that unsafe rust is then unsafer than c++. I haven't learned rust yet, and I get that it's a tradeoff because the rest of the system can still be relied on. But how true is that first statement?
tialaramex 49 minutes ago [-]
It's not helpful to think of it as "unsafer" but I think the way I'd explain this goes as follows:
Rust has some stricter and more complicated rules even than a language like C++. Just as in C++ you absolutely must obey these rules at all times. However, in Safe Rust the tooling will ensure that following those rules is never your problem. You don't even need to know what the rules are, just like you don't need to know why a plane works let alone how to fly it to get on a jetliner and fly across the country for $$$.
In unsafe Rust, it is your job as programmer to understand and obey these rules because the "unsafe super powers" you can use only in these blocks cannot be checked by the tooling, it can help sometimes but you can't rely on it. Writing ten lines of correct unsafe Rust is thus probably significantly harder than writing ten lines of C++. But the Rust programmer knows when they need to be at their sharpest, they need proper review by somebody paying attention, they need to slow down and think it through, versus the rest of the safe Rust where it's less scary, in C++ every line you write might be a fatal problem.
Basically, walking a tight rope is harder than everyday walking, but you know when you're on a tight rope, you've trained for it, everybody is focused on your safety - so actually maybe that's not a problem, lot of people get injured just walking about every day.
Tuna-Fish 4 hours ago [-]
Rust allows much more aggressive optimization of the reference types than C++. If you have a &T, the compiler can assume that it will not change over the entire lifetime of the reference, and reorder things even past things that a C++ compiler would never reorder across. This can easily bite you badly if you have the mental model of C/C++ pointers and step into unsafe land. There is a separate warning for:
unsafe {
mem::transmute::<&T, &mut T>(t) //takes a &T, returns a &mut T
}
in the compiler because this is something that a lot of people think might be safe (I'm running single-threaded, everything would be so much simpler if I just mutated this bit while no-one's looking), but is in fact pretty much always UB of the nasal demons type. But there are more ways to step on this problem than the most apparent way, and the compiler is not able to protect you from all of them.
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.
imtringued 2 hours ago [-]
That statement is incorrect.
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.
applfanboysbgon 10 hours ago [-]
> 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.
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.
galangalalgol 8 hours ago [-]
The autovectorizer works quite well in llvm with all the aliasing guarantees rust gives it. Especially now fastmath hit so wide types aren't necessary anymore. I don't need unsafe or crates that use unsafe to beat the performance of c++. If you are doing something very specific with niche intrinsics llvm can't use, then maybe I'd have to use unsafe. But I don't run into that. Rust is faster for the same reasons it avoids UB. Also the Kool aid comes in multiple flavors!
7 hours ago [-]
mokre 14 hours ago [-]
What with this llms not so good in rust mantra? Something changed?
In my experience they are pretty good, but haters gonna hate.
JoshTriplett 11 hours ago [-]
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.)
eru 9 hours ago [-]
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.
throwaway2037 3 hours ago [-]
Can you give an example where an LLM produced low quality Python code? Python is such a simple language. This seems hard to imagine. Plus, the amount of open source Python that LLMs can be trained upon is enormous.
Cnidarias 25 minutes ago [-]
I am looking at an MR a colleague threw at me right now where the code quality produced is atrocious.
Multiple redefinitions of enums - except they aren't enum but random lists of strings - that also diverge in different files.
Things consistently typed as `Any` or `dict[str, Any]` even though the functions clearly are expecting specifics, not `Any`
This is the worst MR I've had to review yet in my life. Absolute garbage.
Tanjreeve 13 hours ago [-]
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.
dgroshev 12 hours ago [-]
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.
eru 9 hours ago [-]
It's good that it's punishing when the abstraction are bad: then you notice. With Python or TS, as you say, you get less feedback.
dgroshev 3 hours ago [-]
That's true, although inconvenient for production code that needs to be delivered yesterday.
Sadly, agents don't mind generating gigatons of code instead of refactoring the abstractions.
8 hours ago [-]
burakemir 18 hours ago [-]
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.
gregw2 18 hours ago [-]
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.
mkehrt 16 hours ago [-]
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.
amir734jj 9 hours ago [-]
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.
germandiago 4 hours ago [-]
Just in case slop is not strong enough.
blub 15 hours ago [-]
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.
i2talics 18 hours ago [-]
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.
tialaramex 17 hours ago [-]
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...
ryukoposting 15 hours ago [-]
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.
skavi 10 hours ago [-]
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.
afdbcreid 15 hours ago [-]
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.
throwaway2037 3 hours ago [-]
> 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.
wrxd 49 minutes ago [-]
Their message begins with "As an embedded dev"
tialaramex 22 minutes ago [-]
"embedded" is very vague though. The problem is that both the guy writing PIC machine code for a $5 thermostat and the guy who wrote some Python running on the Linux box inside a Times Square moving advert think they're "an embedded dev".
pjmlp 15 hours ago [-]
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,
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. 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.
zamalek 17 hours ago [-]
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.
tialaramex 12 hours ago [-]
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.
afdbcreid 16 hours ago [-]
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.
zamalek 11 hours ago [-]
I've started distrusting anything good people have to say about Zig because of the wide variety of untrue claims made about it - unless those claims come from Andrew himself. Last time I was assured that compile-time memory guarantees were possible and were going to happen (they didn't: the recent announcement is runtime/debug assertions). Zig is still making massive breaking changes, and while that is not a bad thing, it makes it categorically _not_ production ready.
pjmlp 2 hours ago [-]
Also note that isn't much different from debug heap that MSCV was already having in 2000[0], assuming you didn't want to shell out some money to Insure++{1], BoundsChecker[2] and similar products.
>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"
i2talics 10 hours ago [-]
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.
hn_submit 14 hours ago [-]
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.
el_benhameen 13 hours ago [-]
Native AOT with C#/.net has come a long way, fwiw.
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.
fishfasell 12 hours ago [-]
Rust is a serious contender for the next mainstream, widely adopted low level language.
nicoburns 16 hours ago [-]
Indeed, unless you're using Safari, you're almost certainly using Rust code to read this webpage.
afdbcreid 15 hours ago [-]
Allegedly, there is Rust in macOS (but maybe not in iOS), so maybe it's true even if you're using Safari.
pjmlp 2 hours ago [-]
Why, when they have Swift for that role?
Havoc 17 hours ago [-]
For me it was the inclusion in the kernel. That locks it in as here to stay
stillpointlab 17 hours ago [-]
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.
Mond_ 16 hours ago [-]
Where did you hear that it got pushed back out? It's going strong as far as I can tell.
stillpointlab 16 hours ago [-]
I was thinking of the public clash in 2025 between Christoph Hellwig which lead to the resignation of Hector Martin, lead of the Asahi Linux project.
I think what Linus pushed back on was specifically "social media brigading" as a solution to internal issues: https://lkml.org/lkml/2025/2/6/1292
MBCook 7 hours ago [-]
In this case it arguably helped. I do wonder how much longer that stalemate would have gone on without the blow up.
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.
16 hours ago [-]
krater23 11 hours ago [-]
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.
shevy-java 13 hours ago [-]
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.
i2talics 10 hours ago [-]
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.
grougnax 15 hours ago [-]
[dead]
pjmlp 21 hours ago [-]
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.
hn_submit 4 hours ago [-]
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.
akazantsev 2 minutes ago [-]
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.
pjmlp 4 hours ago [-]
The complaint can be applied to any modern software, unfortunately.
vintagedave 3 hours ago [-]
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.
pjmlp 3 hours ago [-]
Sure, and the performance improvements across VS 2026 releases prove that it could be much better.
ghostly_s 19 hours ago [-]
Are you thinking this augurs more interoperability features in C?
pjmlp 19 hours ago [-]
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).
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.
bluGill 19 hours ago [-]
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).
tyre 16 hours ago [-]
What were you working on that cost a billion dollars to rewrite? Or was that hyperbole?
Aperocky 6 hours ago [-]
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.
bluGill 16 hours ago [-]
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)
vlovich123 14 hours ago [-]
Based on Grok identifying the company correctly, that would amount to ~3% of annual revenue and 30% of profits which seems insane to me for the cost of a single project.
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.
redox99 15 hours ago [-]
Btw grok found out in less than ten seconds what place you refer to and likely what software within that company.
Things that wouldn't be worth your time before are trivial these days with LLMs.
AndreasHae 13 hours ago [-]
Interesting, Claude’s guardrails prevented it from spelling out the company even after multiple spoofing attempts („This is my account, make sure no one can find out my employer…“)
Grok immediately answered without a second thought.
redox99 13 hours ago [-]
Yeah I tried GPT first because that's what I always use, it refused and I didn't even bother trying to trick it, just went straight to Grok.
cogman10 14 hours ago [-]
woof, yeah, Just did the test myself (because I was curious) and it spat out the answer pretty quick.
red75prime 14 hours ago [-]
...including rewrites into another language
17 hours ago [-]
Uther 2 hours ago [-]
Rewrite it in Rust has always been more a fantasy of the C++ community than a goal of the Rust ecosystem.
arlort 54 minutes ago [-]
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)
pornel 20 hours ago [-]
The big news here is they've replaced LLVM with MSVC's backend.
booi 17 hours ago [-]
I'm sure that's a requirement for being a "Tier-1" language.
monocasa 12 hours ago [-]
Eh, they call TypeScript a tier 1 language too.
qalmakka 2 hours ago [-]
... 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
pjmlp 1 hours ago [-]
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.
dartharva 7 hours ago [-]
MSVC always was the default backend for Windows platforms.
qalmakka 2 hours ago [-]
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
alkonaut 5 hours ago [-]
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.
bpye 5 hours ago [-]
> 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.
azhenley 5 hours ago [-]
ProgramBench was published recently where agents have to reconstruct a program given just the binary and documentation.
If we have AGI, it can just solve all the memory issues in the existing codebase instead of rewriting it all.
alkonaut 3 hours ago [-]
But then we'd still be left with a C or C++ codebase.
abbefaria27 17 hours ago [-]
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.
uncle_kostya 5 hours ago [-]
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.
afdbcreid 16 hours ago [-]
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.
nicoburns 16 hours ago [-]
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).
Calling Rust from C++ seems to be more technically straightforward than the reverse.
kibwen 16 hours ago [-]
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).
drop_star 17 hours ago [-]
ya our codebase is 30m lines of c++
apatheticonion 11 hours ago [-]
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.
throwaway2037 2 hours ago [-]
> 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.
tcfhgj 1 hours ago [-]
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.
strix_varius 10 hours ago [-]
> 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.
apatheticonion 8 hours ago [-]
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.
ThunderSizzle 10 hours ago [-]
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#?
apatheticonion 8 hours ago [-]
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.
za3faran 4 hours ago [-]
We've seen several anecdotes where JIT languages (e.g. Java) outperform Rust in throughput and latency in long-running server programs.
drzaiusx11 10 hours ago [-]
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.
tcfhgj 52 minutes ago [-]
Still, it's fast enough that Rust frameworks can compete with the fastest JS frameworks on UI benchmarks [1]
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.
If it is a tier-1 language why isn't it supported in Visual Studio?
brunoborges 20 hours ago [-]
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.
pdpi 20 hours ago [-]
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.
isolay 19 hours ago [-]
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.
bluGill 19 hours ago [-]
Most people don't have a choice. Corporate IT has choosen what I run my machine on. I have used a native linux machine, but since my email is still on outlook, everybody uses teams, and all the non-code documents are on windows I end up having to have a windows machine. Linux in a VM under windows ends up being the easiest workflow (though I'm just starting to try WSL and so far it is looking good)
disgruntledphd2 19 hours ago [-]
> (though I'm just starting to try WSL and so far it is looking good)
WSL is really nice, as is Windows Terminal. I particularly love its fonts (but that's probably just me).
throwaway85825 17 hours ago [-]
Did they ever fix terminal performance?
peterfirefly 2 hours ago [-]
Mostly, yes. They didn't really apologize for the abuse they sent towards Muratori but they did essentially wind up with the architecture he proposed.
ocdtrekkie 16 hours ago [-]
I think just running cmd still uses much less memory but Terminal is much, much faster than it was.
philwelch 16 hours ago [-]
Outlook and Teams are both web apps, or at least they were when I last used them. Even if you download the "native" app it's just Electron. I haven't had trouble using either of them on Linux.
bluGill 16 hours ago [-]
Outlook is native. There is the new web version that it says don't use (yet)
tcfhgj 1 hours ago [-]
Which sends your login data straight to microsoft
pjmlp 1 hours ago [-]
Plenty of us do, so far Valve has failed to make native builds for Linux appealing for game studios, even though they already have to deal with similar APIs on Android, iDevices and PS/Switch.
vouwfietsman 18 hours ago [-]
This kind of stuff is why its hard to have good conversations about tooling. Windows is the best place for many kinds of software dev, but perhaps not the kind you are doing.
rafterydj 16 hours ago [-]
When it is not the mandated option, under what circumstances is Windows the best choice for software dev? The only domain I can think of is gaming, and Valve is seemingly coming up fast to eat Microsoft's lunch in the next few years.
pjmlp 1 hours ago [-]
Game development, graphics programming and GUI tooling.
The alternative being macOS, if Apple actually had competitive prices for all kinds of world economies.
dwattttt 12 hours ago [-]
Valve is certainly increasing the viability of Linux as a platform for gaming, but I can't see developers targeting Wine or Linux for a major game over Windows directly. Not for a decade, if ever.
neutronicus 19 hours ago [-]
Visual Studio brings a lot to the table for C++ development. Specifically the Debugger, although IntelliSense also often succeeds at queries that stump clangd.
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.
not_a9 20 hours ago [-]
Visual Studio does have a really nice C++ debugger - one would imagine the C++ debugging capabilities should translate to Rust.
pjmlp 1 hours ago [-]
Hot code reloading, and incremental linking would be great, given the build times.
1 hours ago [-]
jiggawatts 9 hours ago [-]
> 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.
germandiago 19 hours ago [-]
> Even with coding agents
Because of coding agents? :D
sedatk 5 hours ago [-]
Microsoft doesn’t use Visual Studio internally for many of its products such as Windows.
nsoonhui 4 hours ago [-]
This is a shocking news to me. Can you elaborate with sources?
bztzt 3 hours ago [-]
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.
eterm 18 hours ago [-]
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 )
phire 15 hours ago [-]
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.
cwbrandsma 20 hours ago [-]
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.
CodeCompost 19 hours ago [-]
Agreed but I think you need to pry Visual Studio from VB.NET developers' cold dead hands.
neutronicus 18 hours ago [-]
C++ developers, too. I suppose they're splitting out the real powerful stuff (Debugger, LSP) for VSCode's consumption.
afdbcreid 19 hours ago [-]
It is, with extensions (using rust-analyzer of course). I don't know what's the status inside Microsoft.
devy 17 hours ago [-]
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.
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.
throwaway2037 2 hours ago [-]
> 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.
throwaway2037 2 hours ago [-]
> 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?
tcfhgj 1 hours ago [-]
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
fg137 14 hours ago [-]
At least 67% of your comment has nothing to do with this article.
devy 11 hours ago [-]
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").
kevincox 14 hours ago [-]
How does Rust help with 2 at all? IIUC the main requirements were not memory or performance related but TPM and instruction set minimums.
bmitc 9 hours ago [-]
> Windows 11 refused to run on those legacy hardware
What legacy hardware was this?
ComputerGuru 21 hours ago [-]
So when will we get tier 1 debugging support in Visual Studio?
MaulingMonkey 17 hours ago [-]
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
(...I should check on enum visualization, but I suspect it's still poor.)
flohofwoe 21 hours ago [-]
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 ;)
bluGill 20 hours ago [-]
The greybeards rarely used debuggers, and then only to see the stack trace of a core file. They found printf better.
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.
josephg 20 hours ago [-]
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.
koyote 10 hours ago [-]
> 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.
rafaelmn 21 hours ago [-]
Debugger MCP better
josephg 20 hours ago [-]
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.
bluGill 19 hours ago [-]
Try, but what skills are work keeping? We need something cogntive, but not everything. I know a few people who blacksmith as a hobby (often for the physical exercise as much as the work), but most people are happy not knowing how to do that job. I know how to set the air-fuel ratio on a gas engine, but I'm glad I don't need to tweak those parameters while driving (unlike a 1910s car where you did), and I won't miss oil changes on my cars as I move to electric.
lelanthran 17 hours ago [-]
> Try, but what skills are work keeping? We need something cogntive, but not everything.
Are you trying to be funny?
bluGill 17 hours ago [-]
Work should be worth. I'm not sure if that is me or autocorrect.
lelanthran 14 hours ago [-]
It was unintentionally funny then :-)
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)
a012 20 hours ago [-]
It’s all /skills now
pjmlp 21 hours ago [-]
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.
jeroenhd 19 hours ago [-]
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.
mrec 21 hours ago [-]
I'd also love to see MS sponsoring Windows support for a modern linker like mold or wild.
delta_p_delta_x 20 hours ago [-]
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.
jcelerier 19 hours ago [-]
to be fair mold or wild's full link is a few hundred times faster than a link.exe incremental relink
uncle_kostya 5 hours ago [-]
Works already in Visual Studio Code, even seamlessly between C++ and Rust
dethswatch 19 hours ago [-]
RustRover, my friend.
throwaway85825 17 hours ago [-]
I thought rover forced you to use their horrible new UI?
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.)
ldobre 19 hours ago [-]
Also, showing the weather is a great excuse to ask permissions for the user location.
zahlman 17 hours ago [-]
What does that have to do with its RAM consumption, though?
sshine 16 hours ago [-]
What if the user changes location?
Sounds like unbounded, dynamic allocation to me!
mf2hd 16 hours ago [-]
Makes sense, someone turns on a vpn, have to prepare for that.
afpx 17 hours ago [-]
The mac tahoe weather system daemon is also sus
swozey 18 hours ago [-]
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.
zanecodes 16 hours ago [-]
Android's permission system conflates the Bluetooth scanning permission with the "Fine location" permission, because in theory any app that can enumerate nearby Bluetooth devices (including things like nearby Bluetooth Low Energy beacons commonly found in stores and malls) could use that information to locate your phone within a few hundred feet.
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.
wtallis 8 hours ago [-]
I'm sure at least some of those macOS permissions prompts are spurious, but for the most part I think they're genuine red flags of poor software quality if not actual security/privacy threats. When a video game prompts for full disk access, it's probably because it wants to spray config and save files all over my home directory instead of putting them in a platform-appropriate location. When it triggers a permissions prompt about Bluetooth, it's probably using the wrong API to get input from a game controller or the wrong API for identifying what kind of input devices are present. If it triggers the "wants to control your system" prompt, it's probably trying to keep responding to input even when it's no longer the foreground application.
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.)
nicman23 18 hours ago [-]
i prefer the macos mindset if not the actual OS
swozey 18 hours ago [-]
I just looked and I think what I'm talking about, where they folded more specific permission callouts under a broad term "Full disk access" "local devices" etc used to be more granular before they updated that UI to match the iphone. If I got a jumpscare permission prompt on macos, I used to actually be concerned. Now they're all jumpscares for basic stuff.
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.
jen20 16 hours ago [-]
If you really want to see what is doing what, you should install Little Snitch and Little Flocker. Many apps (from exactly the people you'd expect) are doing absolutely unhinged nonsense that no-one should put up with.
swozey 14 hours ago [-]
I didn't know about Little Flocker and BlockBlock, I'll have to check these out. I do a lot of game modding dev work and people are using mods as attack vectors all the time now and it's made me wanting to ebpf lockdown everything.
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.
yeah i mean security is opposite to convenience until it is really really not
mf2hd 16 hours ago [-]
Ah, most of the people just click yes, yes, allow, allow, yesIamsure, next. Especially when the system is training them to do exatly this by these meaningless warnings you described.
The forest job sounds nice :)
throwaway894345 17 hours ago [-]
Unrelatedly, I'm still trying to figure out why Apple requires me to unlock my phone to look at the weather. Is there some concern that someone could pick up my phone and learn what city it is in?
jshier 17 hours ago [-]
You can use the weather widget on the lock screen, and as long as you have lock screen content when locked enabled, you can see the current area's weather just fine. Or do you want the whole app experience?
throwaway894345 17 hours ago [-]
The lock screen widgets don't tell you much more than what you can get from looking outside. It's not very helpful to know that it's currently overcast and raining, but it would be a lot more helpful if I could know when the rain is supposed to stop or what the week's forecast is and so on.
throwaway27448 17 hours ago [-]
I'm a little too lazy to experiment, but it wouldn't surprise me if that widget didn't function normally until the phone is unlocked.
jen20 16 hours ago [-]
I just tried it. It works fine.
throwaway27448 16 hours ago [-]
The software can read from the phone without unlocking it?
jshier 14 hours ago [-]
After the first unlock after a reboot yes, except for those items with very high security (usually just keychain items) that require an unlock for every access. Lock screen items can be locked every time you lock the phone, or set to allow access while locked (after first unlock). Unfortunately this is an all or nothing setting, unless the widget specifically uses the redaction views to hide content.
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.
throwaway27448 11 hours ago [-]
So—the widget doesn't function normally until the phone is unlocked?
I don't want to flex but that seems worth acknowledging from every perspective
jshier 10 hours ago [-]
Until the first unlock after a reboot, no, like I said. Given how rarely iOS devices are rebooted it's not an issue.
17 hours ago [-]
freeplay 17 hours ago [-]
You want to be able to launch apps without unlocking your phone? Slippery slope.
kevin_thibedeau 16 hours ago [-]
Camera app does it.
derefr 15 hours ago [-]
Nope; the lockscreen camera is actually an entirely different app, or not-quite-app thing. (Note what happens when you open the camera roll in the lockscreen camera.)
throwaway894345 17 hours ago [-]
If the app doesn't have any sensitive information, then yes. We already do this with home screen widgets today, so clearly there's no real barrier.
zamalek 17 hours ago [-]
Apps can have vulnerabilities (intentional or not). It's a contrived example, but maybe some weather app has a custom icon feature, which means you can then browse photos by opening it on the lock screen and going to that setting.
Escapado 20 hours ago [-]
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"? :)
xattt 20 hours ago [-]
Todd was a script kiddie and never really knew what he was doing. He changed careers after the layoff and is now an owner of an electrical contracting business.
moooo99 18 hours ago [-]
The longer I work in corporate, the wiser Todd seems
throwaway85825 17 hours ago [-]
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.
missingcolours 16 hours ago [-]
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"
torginus 16 hours ago [-]
I don't think this is a real dilemma - people hell bent on avoiding work can get by without shipping a single line of code for years.
jm4 17 hours ago [-]
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.
throwaway27448 17 hours ago [-]
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.
zahlman 17 hours ago [-]
1GB is space for almost half an hour of 5000kbps ("YouTube Premium") video. Just what kind of eye candy are we talking about here?
monocasa 16 hours ago [-]
It's also only 45 frames uncompressed at 4k. It's remarkably easy to hit that if your base assets are mostly raster rather than vector for a dynamic scene.
Obviously, they should try harder, and this is an explanation rather than an excuse, but the graphics assets are mostly why.
zahlman 2 hours ago [-]
Why would you need that kind of resolution for a weather app? What are you even going to depict with all those pixels?
throwaway27448 11 hours ago [-]
I have deep faith you can find the imagination with in you to understand
nikanj 16 hours ago [-]
Sally, obviously. Todd is much more likely to have a perfect haircut and immaculate fluency in corpotalk
xyst 19 hours ago [-]
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?
villish 17 hours ago [-]
The list of professions made obsolete is very long. Why should programming be protected if AI in the future can make software better, safer, and cheaper?
miroljub 20 hours ago [-]
[flagged]
delta_p_delta_x 18 hours ago [-]
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.
MarleTangible 16 hours ago [-]
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.
pocksuppet 5 hours ago [-]
That is how apps work in 2016 onwards (the last decade).
pjmlp 20 hours ago [-]
The problem is the Webview2 prevalence, and note many Rust projects love their webviews as well.
airstrike 15 hours ago [-]
Not the ones made with iced <3
pjmlp 4 hours ago [-]
Yeah, however there are probably much more using Tauri.
onlyrealcuzzo 19 hours ago [-]
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.
throwaway894345 17 hours ago [-]
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.
afdbcreid 16 hours ago [-]
> 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).
meerita 11 hours ago [-]
I was a little bit scared at first, but after 1k lines of code written by hand I started to forget that Rust was complicated. It's not the Go experience, but it's not that bad at all.
sn9 15 hours ago [-]
Have you considered doing this in OCaml?
You'd get most of the benefits of Go and Rust.
isolay 19 hours ago [-]
Whether vibecoded Rust will be better than whatever they are doing now remains to be seen.
mr_00ff00 19 hours ago [-]
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.
"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.
ben-schaaf 17 hours ago [-]
There's premature optimisation, where you write a whole bunch of complicated code to avoid cloning an Arc<>. And then there's "premature optimisation" where you skip any consideration for performance until it becomes a problem.
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.
afdbcreid 16 hours ago [-]
"Keep calm and clone" is a good advice for beginners. Then it is also a good advice for experts - because when you're an expert and you just think of cloning, that probably means it is easier than borrowing which you would default to.
JoshTriplett 16 hours ago [-]
By all means use borrowing if it's straightforward. But don't necessarily upend your whole codebase to avoid one clone, either.
bananamogul 15 hours ago [-]
Isn’t the latter what Knuth meant?
Such a slippery slope between “consideration of performance” and optimization.
cogman10 15 hours ago [-]
The full quote
> 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.
Barrin92 16 hours ago [-]
The question to me in terms of memory is, if you're writing a weather app on windows why are you not using C#.
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?
tcfhgj 29 minutes ago [-]
Now that WinUI has a Rust API, I think using Rust is a no-brainer.
The app will be running on probably about a billion of devices, and Rust will reduce the footprint on each of those - assuming not a vibe coded clone app.
The additional effort isn't that big, and it would make the experience of maaaany users a bit better still.
Now extrapolate on all windows included apps and ui elements.
How much would that cost per license?
isolay 4 hours ago [-]
Maybe they fired all their experienced developers and only have cheap vibecoders now, I don’t know. The decisions of beancounters and lawyers that control these companies are mysterious to me.
bluGill 19 hours ago [-]
The other things I've seen beginners do is throw unsafe at everything.
tredre3 18 hours ago [-]
The things that unsafe enables are arbitrary pointers, FFI, and accessing union members in a C struct. It seems highly unlikely to me that unsafe would fix any beginner's problem.
.clone() on the other hand is indeed an easy/quick fix for a lot of issues you'd face when learning rust.
suddenlybananas 18 hours ago [-]
I think beginner programmers are unlikely to use unsafe when learning rust but people coming from c or c++ who are beginners at rust might use unsafe all over the place.
bluGill 18 hours ago [-]
Exactly - we have been using C or C++ for decades and most of us have a lot of experience. We think like programmers in the languages meaning we often do things that Rust won't allow without unsafe. A small percent of the time that is the right thing (which is why Rust have unsafe), but very often there is a Rust way that is just as performant if only we knew how to think like Rust programmers.
Pannoniae 18 hours ago [-]
Sadly it still feels like it's one of the languages where the language doesn't trust you, it tries to force you to do things "the right way". I do love quite a few of its design like how traits are, not forcing every method into the declaration, and the standard library is much less crazy than the C++ version.
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...
bluGill 16 hours ago [-]
Most of the time the rust way is just as good, just different.
rblatz 17 hours ago [-]
Yeah it doesn’t trust you, and for good reason the decades of developers making the same mistakes over and over again. If everyone was perfect you wouldn’t need Rust, but no one is perfect and that’s why Rust exists.
uecker 18 hours ago [-]
Yes, but this this is not a problem at all because any bug caused by misuse of unsafe (or unwrap) is entirely the fault of the programmer (or the AI) and not of Rust. /s
stefan_ 17 hours ago [-]
Actually they just Arc<T> everything
dismalaf 17 hours ago [-]
Instead of leaking memory it'll just clone the whole heap over and over.
hirvi74 17 hours ago [-]
I seriously do not think things could be any worse.
CamperBob2 17 hours ago [-]
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.
geodel 20 hours ago [-]
But Tier-1 app consuming Tier-1 RAM seems officially approved.
iw2rmb 13 hours ago [-]
I can't comprehend why 250 MB for a weather app on macOS is considered normal.
jordand 17 hours ago [-]
It won't, that 1GB+ belongs to Microsoft's advertisers and their many video ads
MarleTangible 16 hours ago [-]
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.
unixhero 18 hours ago [-]
And that the calculator does not take 5 seconds to load
_s_a_m_ 15 hours ago [-]
are they launching for the graphics in the background the whole MS Office and PowerPoint?
pessimizer 16 hours ago [-]
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.
nalekberov 16 hours ago [-]
Does it matter when one embeds web browser into their app?
you jest but F# already does the ocamlness of Rust, no? and you don't need a borrow checker.
layer8 19 hours ago [-]
For tracking ownership of non-memory resources you still need something like that.
Havoc 17 hours ago [-]
What a cursed comment haha
boredatoms 20 hours ago [-]
I guess we should watch for contributions to Servo
stillpointlab 17 hours ago [-]
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).
Havoc 10 hours ago [-]
What other langs do they consider tier 1? What’s in tier 2?
splicebot 15 hours ago [-]
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).
psyclobe 13 hours ago [-]
Microsoft is a tier-0 company.
rererereferred 18 hours ago [-]
But which GUI toolkit will they use for all their new rust applications?
tcfhgj 16 hours ago [-]
WinUI (3) via Windows Reactor
HPsquared 19 hours ago [-]
Visual Rust sounds like a defect but I'm looking forward to it.
the__alchemist 20 hours ago [-]
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.
jdcasale 20 hours ago [-]
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.
jorelfermin 8 hours ago [-]
jdcasale you are right that Arc<RwLock<T>> is a code smell but I would take that a bit further that locking immutable data is even more of a smell. The real bad guy in this case is the RwLock not Arc. For anything that you hydrated once and never mutate you do not need the RwLock. Arc just clones the pointer so it is safe to share for concurrent reads so something like Arc<T> is fine and if you need initialization locking then LazyLock<Arc<T>> lets you lock the initialization but then everything else is just a pointer copy.
I hit this recently while building a url unfurl social card renderer for a project which ended up being something like LazyLock<Arc<Database>>
germandiago 19 hours ago [-]
Give me something like boost.multiindex for Rust, and maybe I could think of trying some experiments.
I think C++ is an excellent choice due to its volubility actually. Bc when I want safety, I mostly have it (but I have done a lot of C++, admittedly).
the__alchemist 20 hours ago [-]
It is interesting to see the different patterns used due to different cases and tastes. For example, my concurrency patterns rarely use locks, and are instead usually one of:
- Dedicated hardware via DMA, multiple cores/MCUs etc
- Thread pools (e.g rayon)
- GPU
- SIMD
- Atomics
- Interrupts and their ISRs
- Event loops
- std::sync Thread and MPSC (My Std rust default for not blocking the GUI etc)
surajrmal 19 hours ago [-]
Most of it comes down to avoiding shared data. Unfortunately it requires forethought to do that well. There are also many cases where you do want to share data for optimal performance as other options are ultimately too heavyweight.
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).
m00dy 20 hours ago [-]
yeah, locks are expensive.
Verdex 20 hours ago [-]
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.
saghm 20 hours ago [-]
I've said for a while that the main reason Rust is so popular is that it has a lot of effort put into the developer experience, with the low-level safety honestly not being all that important to a large portion of the programmers who would be fine with a garbage collector. I used to think that maybe a "Rust with garbage collector" would come along, but at this point it honestly seems more likely that an optional garbage collector would be added to Rust (probably with just the primitives in std and leaving it up to libraries to provide a more full experience, like with async runtimes).
Surac 19 hours ago [-]
a rust with gc is already available. it is called c# and runs on all os nowerdays
saghm 16 hours ago [-]
No, a class-based OO language where you need to spend effort crafting build targets by hand or use an IDE to define how to build is not anything close to what I'm talking about. If you think that it's "Rust with GC", I think you're misunderstanding what actually appeals to most people about Rust.
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.
mgaunard 20 hours ago [-]
All those applications area sensitive to asynchronous programming.
okanat 20 hours ago [-]
Rust's async can be very lightweight depending on the runtime implementation. tokio and embassy are both runtimes but former is a throughput-optimized heavily multi-threaded while latter is a simple cooperative multitasking for embedded. We use both at my day job. Even 64k flash and 16k ram is enough for embassy.
mook 20 hours ago [-]
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.
ogoffart 27 minutes ago [-]
Slint ?
bigfishrunning 20 hours ago [-]
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)
vablings 20 hours ago [-]
Rapid prototyping is almost a meme at this point. If you are hand rolling code old school, you will waste more time shoehorning JavaScript and python semantics into rust code and end up with worse quality that takes more time rather than writing it from rust.
People did this a lot when rust was not as popular but there are plenty of very good rust programmers now who understand the language and can make programs that are significantly more performance for a marginal development cost.
Script ability can also be done in rust, Notably Zed (rust ide/vscode whatevers) is written in rust, and all the plugins are compiled to WASM, sandboxed and loaded.
Go is pretty nice for server-side API but if your application share types between boundries then rust is better
germandiago 19 hours ago [-]
> Rapid prototyping is almost a meme at this point
> 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.
vor_ 37 minutes ago [-]
> Why isn't the game industry moving to it then?
The most obvious answer is that requires official support from the platform manufacturers.
tredre3 18 hours ago [-]
> Why isn't the game industry moving to it then? Bc it just cannot compete at volubility with C++, among other things.
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.
germandiago 4 hours ago [-]
> The actual reason is much simpler. The industry is built on a handful of game engines
This is a strong reason, but then why in other areas they consider it over C++ for greenfield but it hardly happens in games?
longor1996 1 hours ago [-]
Because retooling and relearning development pipelines (on any level/most teams) for games is a horrifically expensive and time-consuming affair... which are resources not spent on developing any one of the potentially dozen or so games. It's just priorities, alas.
gregw2 18 hours ago [-]
Why isn't the game industry moving to rust?
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...).
bigfishrunning 17 hours ago [-]
It seems like you're comparing "start from scratch in rust" to "start with an existing game engine in some other language". That's not really a fair comparison. there are popular game engines in rust (although i think they're mostly smaller/more niche then something like unity or godot), bevy comes to mind.
SleepyMyroslav 18 hours ago [-]
I work in gamedev. Here is a simple answer: proprietary gaming platforms have no plans to support Rust.
mrec 19 hours ago [-]
I don't think "volubility" means what you think it means. The usual meaning of "voluble" is "talkative" (gesprächig if your username is accurate). I'm not quite sure what you're going for here or in an earlier comment, but suspect it's something more like "ergonomic", i.e. the language being easy/natural to write and not getting in your way.
germandiago 4 hours ago [-]
> I don't think "volubility"
Indeed I got it wrong bc I translated from spanish and it seems to be a false friend. The word I meant is "malleable".
eviks 6 hours ago [-]
> Script ability can also be done in rust, > Notably Zed ... the plugins are compiled to WASM, sandboxed and loaded.
It notably doesn't have any plugins relevant in this scripting context. It only has themes/language syntax/servers, nothing about actual editing
Pannoniae 18 hours ago [-]
No, rapid development is essential when you're making games. It's not a "solved science", sure you can code something up and slap some programmer art on it then ship it but you very well know that won't be usable. You need to iterate on the gameplay and gamefeel a lot if you want something more than slop.
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;)
bryanlarsen 20 hours ago [-]
Rust is great for rapid protoyping, IMO. Or, at least the subset of rapid prototyping that involves massive rewrites to try out different approaches. Rust has a saying "if it compiles, it works", the compiler really ensures that you don't miss something when doing that rewrite.
germandiago 19 hours ago [-]
> Rust is great for rapid protoyping, IMO
If you have to iterate a lot the shape of your code... no, it is not any good at this...
edukite 20 hours ago [-]
My employer company go through JavaScript, Java, Golang and at the end landed on Rust for srver side and don't want to change anything. Everything is Rust now, regardless of traffic.
I don't know why you think it's only usable but this is your right.
bigfishrunning 19 hours ago [-]
I do think rust works there (as you clearly know), i just like Go's ergonomics for that exact task better, that's all.
larme 19 hours ago [-]
GPU programming?
the__alchemist 19 hours ago [-]
Rust is great for GPU programming, or at least for writing the Host (CPU) side without friction. WGPU or FFI-based Vulkan etc bindings for graphics. Cudarc + normal Cuda kernels for general purpose compute. I bring these up as they're easy-to-use and mature.
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.
hn_submit 14 hours ago [-]
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.
imglorp 14 hours ago [-]
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?
MBCook 7 hours ago [-]
New CEOs can do that to a company.
Surac 19 hours ago [-]
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
ellyagg 19 hours ago [-]
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”.
KingOfCoders 19 hours ago [-]
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.
lukaslueg 16 hours ago [-]
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.
_joel 21 hours ago [-]
Site down, maybe they need port it to use Rust...
They use wordpress
seki285 20 hours ago [-]
What is wrong with wordpress exactly?
bluGill 20 hours ago [-]
there are a lot of really bad plugins that are used. Also there are a lot of really bad admins who have out of date versions that are misconfigured.
mcmcmc 20 hours ago [-]
Matt Mullenweg
jcelerier 19 hours ago [-]
wordpress
echelon 20 hours ago [-]
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.
tonyedgecombe 20 hours ago [-]
I like Rust a lot but I'm not sure it would come very high up my list for web applications.
insanitybit 16 hours ago [-]
At work we're moving almost everything to Rust on our backend. Massively reduced memory usage and significant latency improvements relative to our Typescript codebase. Even for code that you'd expect to work well in TS, a near 1 to 1 port to Rust has considerably improved our best case and, in particular, our worst case latencies. And the memory we get back is huge, we may even drop our instance size down with the 800MB of RAM we're likely going to save.
za3faran 3 hours ago [-]
To be fair, it's not that hard to get an improvement compared to running TS in the backend.
echelon 20 hours ago [-]
Axum and Actix are phenomenal web frameworks.
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.
germandiago 19 hours ago [-]
> Axum and Actix are phenomenal web frameworks
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.
tomrod 18 hours ago [-]
Say more. I need me proper rust in the browser.
20 hours ago [-]
edukite 20 hours ago [-]
First compile. Every another will be significantly faster since compiler is incremental
macleginn 20 hours ago [-]
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.
stevetron 17 hours ago [-]
So, Rust.NET?
4petesake 15 hours ago [-]
VisualRust.NET Copilot
guywithahat 17 hours ago [-]
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
paaloeye 15 hours ago [-]
I'm wondering how they deal with long compilation times
FrustratedMonky 19 hours ago [-]
As much as I like Rust. Still sad that F# didn't get this much support from their own mother.
Colegno 19 hours ago [-]
Being technically approved by Microsoft is not a proof of quality...
afdbcreid 19 hours ago [-]
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.
bryanlarsen 17 hours ago [-]
Google announced that Android contains 5 million lines of Rust last year; sounds Tier-1 to me.
afdbcreid 17 hours ago [-]
Android is a bit special inside Google (also Chromium). They are managed outside the main monorepo (google3) and their policies are different. From what people inside Google have told me, they do want to introduce Rust into google3 but that work has only begun.
kccqzy 16 hours ago [-]
They wasted a few years trying to introduce Swift then Carbon because they thought the Rust C++ interop wasn’t good enough.
axus 18 hours ago [-]
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.
minimaxir 17 hours ago [-]
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.
hanw040519 14 hours ago [-]
We don't learn Rust at school at all(both undergratuate and gratuate student)
AJRF 12 hours ago [-]
i've never seen such a damning indictment of a language.
divs4real 15 hours ago [-]
started learning rust using the rust programming language book last month!
tylerchilds 11 hours ago [-]
How the open source turn tables have open source turned
bitwize 17 hours ago [-]
NT kernel rewrite when?
larodi 20 hours ago [-]
ermm... which are the rust-native libs which enable winrt3.0 native apps?
tcfhgj 16 hours ago [-]
Do you mean winui3?
windows-rs
larodi 15 hours ago [-]
winui3, yes. but afaik windows-rs is the generic crate, right? not something ms released as rust-first approach to winui3?
tcfhgj 2 hours ago [-]
It includes Windows Reactor, a fairly new API for WinUI Apps
DidntUseIt 21 hours ago [-]
Link doesn’t work.
What’s a Tier 1 language?
meindnoch 20 hours ago [-]
Tier 1 is the summit of summits - the summum bonum of languages, the highest order to which a language can aspire. Very few ever attain it. Non multa, sed multum: not many, but only those of extraordinary quality. Most languages remain forever in Tier 3, never passing beyond its gates. Of these, scarcely 1% ascend to Tier 2. And from that already distinguished company, a mere 0.1% possess the refinement, depth, and excellence required to cross the final threshold into Tier 1.
Consider what that means: Tier 1 represents roughly the top 0.001% of languages. Pauci sed electi - few, but chosen. The crème de la crème. The aristocracy of languages. Primus inter pares, yet standing at the very edge of what programming language greatness can be.
Ad astra per aspera. Through hardship, to the stars. Tier 1 is not merely another rank: it is the ultima Thule, the farthest frontier, the crown, the apotheosis.
DidntUseIt 20 hours ago [-]
The answer I deserved!
gshubert17 21 hours ago [-]
(Link worked for me ...)
This “Tier-1 language” engineering status for Rust means giving internal teams a paved path from local development to production: secure toolchain builds, productive developer tooling, quality workflows, deep platform integration, and compliance with the SDL requirements Microsoft software must meet.
swiftcoder 20 hours ago [-]
Specifically, it joins a list of existing Tier 1 languages (C++, C#, and TypeScript), as "one of the best-supported languages for internal development at Microsoft"
theanonymousone 17 hours ago [-]
Java and Python are not on that list?
monocasa 16 hours ago [-]
Microsoft explicitly de-emphasized Java in favor of C# after their J++ lawsuit. That's why they created C# in fact.
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.
flohofwoe 20 hours ago [-]
It means it's about as good as C++ ;)
afdbcreid 19 hours ago [-]
Yes, about as good as a language that is 40 years old, and was also (like Rust) 10 years old when becoming Tier 1 inside Microsoft, while there were far less alternatives.
Seems pretty good to me ;)
(I know you're joking).
sehw 16 hours ago [-]
[dead]
aynyc 20 hours ago [-]
It means a language for the very elite special force unit. In MSFT, that means the Ads teams will be able to serve you Ads in excel very quickly. /s
nacozarina 16 hours ago [-]
… and they proved you can still write tier-10 software with it
prisonguard 15 hours ago [-]
LOL!
up2isomorphism 12 hours ago [-]
So do we observe overall Microsoft software quality improvement so far?
lasky 11 hours ago [-]
who cares. AI will translate brain waves to binary within 5 years.
tenox7 6 hours ago [-]
VisualRust#
astarc 15 hours ago [-]
It is a decompiled language.
dismalaf 17 hours ago [-]
If I were the Rust foundation I'd be keeping this to myself right now.
smcin 12 hours ago [-]
Why?
mgaunard 20 hours ago [-]
does it mean there is a rust.net?
dralley 20 hours ago [-]
There is a rustc_codegen_clr which transpiles to .NET
> This project is still early in its developement. Bugs, crashes and miscompilations are expected. DO NOT USE IT FOR ANYTHING SERIOUS.
how can one claim it is tier-1?
Also random student, nothing official from Microsoft.
debugnik 18 hours ago [-]
We thought your Rust.NET comment was somewhat in jest. No, Microsoft isn't porting Rust to .NET, they barely try to support anything other than C# on it nowadays, but the article mentions an internal adapter for MSVC codegen.
The project linked above has been posted to HN in the past a few times though.
pali6 20 hours ago [-]
That project is not in any direct way related to Microsoft
DidntUseIt 20 hours ago [-]
Just had a PTSD flashback...
The year was 2002, VB6 had just been retired for VB.NET which had 0 backward compatibility.
And then we all became Flash/AS3 developers.
The End
4petesake 15 hours ago [-]
Cold Fusion 1,000 mile gaze says hello
Alien1Being 9 hours ago [-]
Waiting for the deluge of Rust cultists....
okokwhatever 15 hours ago [-]
This thread deserves a meme
this_user 20 hours ago [-]
Now their broken slop code is at least memory safe.
ArsenDjukic 17 hours ago [-]
[dead]
shevy-java 13 hours ago [-]
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.
burakemir 19 hours ago [-]
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.
tobin1994 2 hours ago [-]
[dead]
TimurRakhmatull 9 hours ago [-]
[flagged]
marsven_422 6 hours ago [-]
[dead]
cnrcode 19 hours ago [-]
[dead]
LazyIDE 21 hours ago [-]
[flagged]
sehw 16 hours ago [-]
[dead]
grougnax 15 hours ago [-]
[dead]
globalnode 6 hours ago [-]
Yet another good reason for me to steer clear of the language.
adikshatriyag 18 hours ago [-]
crazy i like that
superkuh 18 hours ago [-]
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.
0x457 18 hours ago [-]
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.
estebank 18 hours ago [-]
I suspect GP is using system rustc to build random projects off of github and doesn't use one of the distros that actually updates rustc, like Fedora, SuSE or Arch.
Then the conversation is about forward compatibility, whether developers should wait X amount of time before using new std APIs or features, and whether the ease of using rustup and project expectation of it being accessible is reasonable or not.
0x457 14 hours ago [-]
Well, "core" community projects have pretty decent MSRV for forward compatibility.
i2talics 18 hours ago [-]
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.
m3kw9 18 hours ago [-]
Good, C# is one of the worst languages there is, hopefully they turn it in to tier 18
hatefulheart 16 hours ago [-]
Sephora is tier-1 at the Clown convention
calvbak 21 hours ago [-]
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.
VimEscapeArtist 19 hours ago [-]
M$ choosing Rust might be the strongest argument for picking Go instead
germandiago 19 hours ago [-]
They strike different balances.
Rust is absolute performance, similar to C++. Go is deliver fast and get a very good performance to effort ratio.
VimEscapeArtist 16 hours ago [-]
It was meant as sarcasm, but judging by the downvotes, I clearly didn’t land it :)
mtgh2s 20 hours ago [-]
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.
nazgulsenpai 20 hours ago [-]
Probably the fact they're a $3.7tn company has something to do with it.
zapzupnz 10 hours ago [-]
Embrace.
Extend. <-- You are here.
Extinguish.
We may never actually reach Extinguish. That won't be by Microsoft's choice, though.
Rendered at 11:02:39 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
Because it's referring to long running processes, AKA the kind of things where hot paths can be JITted into faster native code than is possible from static compilation because the JIT has information about the real-world usage patterns.
> Meanwhile when I run tests on my JVM projects it can take 30 seconds just to start
That strongly implies you're using some sort of framework that's doing a _lot_ of initialization. That's not JVM startup time, don't be intellectually dishonest here.
> 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.
Again, the main use case for Java is long running server processes. No one cares if the binary is 1, 10, or 100MB or if it consumes 2, 3, or 4x the memory as long as the throughput is there. And Java has a long track record of delivering very good performance in those contexts, coupled with an extremely rich and mature library/tooling ecosystem.
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.
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.
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.)
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.
Rust has some stricter and more complicated rules even than a language like C++. Just as in C++ you absolutely must obey these rules at all times. However, in Safe Rust the tooling will ensure that following those rules is never your problem. You don't even need to know what the rules are, just like you don't need to know why a plane works let alone how to fly it to get on a jetliner and fly across the country for $$$.
In unsafe Rust, it is your job as programmer to understand and obey these rules because the "unsafe super powers" you can use only in these blocks cannot be checked by the tooling, it can help sometimes but you can't rely on it. Writing ten lines of correct unsafe Rust is thus probably significantly harder than writing ten lines of C++. But the Rust programmer knows when they need to be at their sharpest, they need proper review by somebody paying attention, they need to slow down and think it through, versus the rest of the safe Rust where it's less scary, in C++ every line you write might be a fatal problem.
Basically, walking a tight rope is harder than everyday walking, but you know when you're on a tight rope, you've trained for it, everybody is focused on your safety - so actually maybe that's not a problem, lot of people get injured just walking about every day.
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.
Multiple redefinitions of enums - except they aren't enum but random lists of strings - that also diverge in different files.
Things consistently typed as `Any` or `dict[str, Any]` even though the functions clearly are expecting specifics, not `Any`
This is the worst MR I've had to review yet in my life. Absolute garbage.
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.
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
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...
[1] - https://www.parasoft.com/products/parasoft-insure/
[2] - https://en.wikipedia.org/wiki/BoundsChecker
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 yes, the language team and ecosystem were always making a point of incremental addition rather than full rewrite)
For the same reason a Rust frontend is being developed for GCC.
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.
https://programbench.com/
Required some effort but we're happy with the result.
Calling Rust from C++ seems to be more technically straightforward than the reverse.
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.
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.
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.
Imo bundle size is a bigger issue.
[1] https://youtube.com/watch?v=4KtotxNAwME
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.
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.
[1] https://www.youtube.com/watch?v=uDtMuS7BExE
[2] https://chromeos.google/products/chromeos-flex/
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.
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?
The app will be running on probably about a billion of devices, and Rust will reduce the footprint on each of those - assuming not a vibe coded clone app.
The additional effort isn't that big, and it would make the experience of maaaany users a bit better still.
Now extrapolate on all windows included apps and ui elements.
How much would that cost per license?
.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.
https://www.jetbrains.com/resharper/
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).
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).
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.
The most obvious answer is that requires official support from the platform manufacturers.
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).
https://github.com/fractalfir/rustc_codegen_clr
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.