Microsoft agentically ports Copilot runtime to Rust for $120K

Microsoft agentically ports Copilot runtime to Rust for $120K theregister.com

The Rust compiler remains unperturbed by the antics of the LLM

48 points•pjmlp•11 days ago•62 comments•

#rust #ports #agentically #120k #copilot #runtime #microsoft #microsoft agentically

62 comments

Rexxar11 days ago

They don't have to tell us they are vibe coding everything.

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

GrayShade11 days ago

> file explorer display the "loading" icon infinitely on some directories

Nautilus had that feature 10 years ago, good to hear they've reached parity.

edg500011 days ago

I love Nautilus, but the one I run (42.6) still has that ocasionally. May be fixed in latest stable by now though.

chrischen11 days ago

The line between vibe coding and just coding has now moved. Vibe coding is specifically when the output is not understood by the prompter. Even in the back in the days of the earlier models i used the models to do my basic typing because it was easier than me typing it out…

Icathian11 days ago

Your reply misunderstands the parent comment, I think. MS devs clearly don't understand their output given how garbage it is.

solarkraft11 days ago

That just sounds like normal Microsoft software to me, since way before vibe coding.

szatkus11 days ago

Random infinite loading in Explorer has been there for years at least.

pjmlp10 days ago

While I partially agree, it seems to have paid out, including among several key projects that Web development nowadays cannot live without.

sharktheone11 days ago

Even if they wouldn't be vibecoding. They were able to write slop before AI

tecoholic11 days ago

    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.

This can’t be real. Single file with 30K lines? Which human being is working on it and how much RAM does it take for a code editor to load that with full symbol tree? I am genuinely curious. Is this common? I think most files I come across stretch to maybe 2-3k lines max.

Rexxar11 days ago

30000 is not that big in very old projects with many contributors. There are always one or two files that no one wants to take the time and responsibility to clean up. And 30000 is not a big number for RAM. The fact that you find it choking is more and of an indication of how bad our tools have become than anything else.

For example, until recently the main file for donet runtime GC was more than 50000 lines (it has since been split).

skrebbel11 days ago

Copilot isn’t “very old”.

Zanfa11 days ago

Behold the View.java[0] at 34k lines of human code. IIRC it’s slimmed down a bit these days and used to be more.

[0] https://android.googlesource.com/platform/frameworks/base/+/...

tecoholic10 days ago

Wow. Somehow I feel my software creds just went by a notch by the mere existence of these files.

brewmarche11 days ago

Until recently the .NET garbage collector used to be a single 30,000+ line C++ file. And it was maintained by one person if I remember correctly.

tecoholic10 days ago

Amazed and horrified at the same time.

wayvey11 days ago

I recently saw a ~60k lines / 3mb .cpp file in one vibe coded project (and yes I was a bit horrified) Surprised it works at all but it apparently does. Not really for a human though and even for an LLM it would be more beneficial for it to be split up.

perching_aix11 days ago

I have seen 30k line cpp files even a decade ago (World of Warcraft server emulator, gameplay logic of a boss enemy), and was told it is fairly normal in large software (even 100K not being unheard of), so I'm not sure if it's that much of an LLM thing.

NewsaHackO11 days ago

This has to be 1) early LLM vibe coding or 2) “hand” vibe codingwhere the user asked the LLM to code sections and stitches them together manually, and the programmer is a novice. The second part I speak from experience; got to ~2k before realizing this is out of the script range and started to break it up. Regardless, it would be almost impossible to get an SOTA LLM agent to ever do this.

sajithdilshan11 days ago

The question should be how can they ever let that file grow that big. What kind of engineers were working on that, like I hate seeing any file more than 300-400 lines of code

dgellow11 days ago

If well organized the number of lines of code in a file is really irrelevant. 300-400 loc is a tiny file in any professional project. Splitting in a large number of file doesn’t magically make things simpler to manage, in fact you fragment the context by doing that. And very likely end up with unnecessary abstractions

meerita11 days ago

I wrote to the post of Andrea (a dev from the Copilot team) about their 800K LoC: 128 PRs, shipped incrementally. Existing end-to-end tests ran against the new code at every step.

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.

https://x.com/acolombiadev/status/2100660224298193081?s=20

jsnell11 days ago

> Half of the 832K LoC are mostly tests she answered:

No? That quote is clearly saying the opposite of your summary.

meerita11 days ago

True! I edited.

hollowturtle11 days ago

> The original TypeScript implementation completed 7.55 of those lifecycles per second, while Rust running in-process managed 120 per second - representing a 15.9x speedup on that particular workload.

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

dmix11 days ago

> agents converted 430,000 lines of TypeScript into 800,000 lines of production Rust

The +400k new lines were probably code comments the agents added to everything

meerita11 days ago

832K + 469k of tests.

Read the full thread on Hacker News →

62 comments

Related stories