Microsoft agentically ports Copilot runtime to Rust for $120K(theregister.com) |
Microsoft agentically ports Copilot runtime to Rust for $120K(theregister.com) |
- there are now ridiculous vibe coded localisation in VS2026
- task manager started to not report cpu usage correctly recently (the number becomes stalled)
- file explorer display the "loading" icon infinitely on some directories
- and many other things!
Nautilus had that feature 10 years ago, good to hear they've reached parity.
One of the thorniest conversions was the session.ts file, which was over 30,000 lines of TypeScript that touched all aspects of the runtime.
For example, until recently the main file for donet runtime GC was more than 50000 lines (it has since been split).
[0] https://android.googlesource.com/platform/frameworks/base/+/...
If you've ever used that tool you wouldn't ask this question, since it's obviously fully vibecoded.
Total: ~1,301,378 lines of Rust.
Production: 832,378 Unit tests: ~469,000 Combined: ~1.30 million lines
On top of the 832K LoC are mostly tests she answered:
> Yeap, 832,378 lines of production Rust. the +800K number is production only; unit tests are another +469K on top.
Does this impresses/surprises anyone? Two folds: 1) I believe the most optimized JavaScript code could near the performance of this phase 1 port without optimizations. I would have gone with that first, many would think that would not be as cost efficient but: 2) optimizing the rust code will require 10x the effort of the 1 by 1 conversion, just because you now need idiomatic rust code that likely has nothing to do with a plain translation. So defeating the initial gain, there's nothing to do the bottleneck gets just pushed elsewhere
The +400k new lines were probably code comments the agents added to everything
Don't know what tech stack it is but I'm guessing electron judging by how buggy and slow it is
Really nothing works anymore as great a product full fat visual studio and windows 7 was I don't have time to deal with your bugs
And if LLMs are as great as they make us believe they are, then this should be easily possible.
Greenlets were much faster.
Gil free python gets stuck on all sorts of python locks. It’s slow.
I’m guessing so it can interop easier with C/C++ codebases? Just a stab in the dark, I have no idea.
Though it's the same extension that can't keep its session timestamps straight, randomly hides sessions I was just in (then suddenly remembers them after going in and out of a session), and completely shits itself visually when using OpenAI's models, so maybe it really is just the latter.
I’ve also read that a first version of the file came from a Common Lisp to C++ code generation step: <https://news.ycombinator.com/item?id=23295041>
> you can still do a lot memory management
That’s kinda my point - you don’t really want to trust the LLM to get any sort of memory management right. A system where hard constraints are baked into the language itself and the LLM fights the compiler at compile time removes a lot of hoping the LLM got it right.
Ultimately either works though so use whatever you enjoy