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.
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).
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
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
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!
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…
I'd certainly like to see more of this, yes. It would be great if scipy, numpy, pytorch, etc. would be available universally, if only because you'd use the same function names in every language.
And if LLMs are as great as they make us believe they are, then this should be easily possible.
> 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
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.
Half 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.
Either would have worked, but rust's fussy compiler & memory features is an advantage for LLMs. The more bug catching you can shift out of runtime and into compile time the better since the LLM can fix it
go is even more straightforward for llms imo. It's a dead simple language with a good garbage collector, where 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
I wouldn't say it has lost. Big firms like Microsoft and Amazon are just afraid to use Go since it's by Google, a known evil firm. This doesn't hold back smaller firms that need to move fast.
Probably that they used dynamic workflows to run long agent sessions to do the conversion, like Anthropic did when they ported Bun from Zig to Rust. Minimize Human in the Loop workflows, maximize Agents in the Loop workflows.
It’s the adverb of agentic, which is an adjective to describe something as having agency. I get it was a snark on the word, but it’s actually a legitimate pre-ai term.
they ported their coding harness, something known for being simply an extensible http and subprocess wrapper, into a monolithic blob. They took their bloated and slow coding harness, and turned into an un-maintanable blob.
53 comments
[ 3.3 ms ] story [ 37.3 ms ] threadFor 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/+/...
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>
- 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.
And if LLMs are as great as they make us believe they are, then this should be easily possible.
The +400k new lines were probably code comments the agents added to everything
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
Half 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
I’m guessing so it can interop easier with C/C++ codebases? Just a stab in the dark, I have no idea.
> 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
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