GitHub Copilot is now written entirely in Rust, with AI agents doing most of the porting work.
The migration cost about $120,000 in AI token usage plus about three weeks of a developer's time.
The effort updated the runtime module-by-module until the job was completed, spanning over 135 releases across a 14.5-week time period.
430,000 lines of TypeScript were converted into 800,000 lines of Rust.
This is true, real, and impressive. However, a comment I posted on HN a couple months ago might counterbalance this fact:
GitHub's Copilot cloud agent offering is suffering with a case of some of the worst corporate ADHD I've seen. We built a cloud agentic development pipeline on it, and it seems like almost every other week they silently change something with zero public announcement or documentation that creates real disruption for our team.
That's real, breaking changes to the platform that clearly aren't being tested/reviewed before being pushed to prod. Again with zero public announcement or documentation.
Support is useless – we're paying customers in the 4-5 figures and our tickets go unanswered.
File by file porting can be done almost always with local reasoning. I don't think it proves much for novel projects which still seems to crumble under complexity past a small sloc limit.
Porting a system to rust without changing the observable behavior is not that difficult with AI, and porting to a more strict language is not that remarkable. I have a tough time understanding why people equate straight shot porting where a test suite already functionally documents the behavior or where the prior application can be used as an oracle with success in all coding tasks. I would be far more impressed if someone did a clean room implementation of all of GitHub Copilot, from scratch, and got to a better point than the TypeScript or port codebase.
I have no doubt that if you provide any AI system with an oracle with expected behavior that it can match that oracle with some amount of $ and tokens. I haven't seen any demonstration of anything else. Rewriting a codebase was always a challenge for humans not because of complexity, but because of the time and effort involved in matching the old version's prior behavior. It doesn't have anything to do with the serious level of work required to build something truly new from scratch in a performant way.
Seriously? I have no idea where this cognitive dissonance comes from. Or are people just lying (outwards or to themselves)? A rewrite of this magnitude would easily take a skilled human team months if not years to finish. This is on top of Rust not being an easy language to work with. Which, btw, is the sole reason why not everything is written in C/C++/Rust.
I'm absolutely saying that AI has sped up the porting and rewrite process! It is amazing! But the reality is that rewriting has been part of programming culture since time immemorial. People want to rewrite for performance or for other reasons all the time, and the cost is now relatively low (i.e., now it's an opex line item in cash instead of time investment). But that doesn't mean that all of coding has been solved.
For example, any amount of software development involves fixing bugs, getting feedback from users on ideal workflows, an iteration loop of performance and bug tuning, etc. AI cannot simply create, from scratch, perfect software. Even using the SOTA models on max effort does not produce bug free software of any meaningful complexity or innovation out of the box. All that has changed is that the act of physically writing code and implementing existing patterns is now effectively a marginal cost.
Most line of business software is not e.g., delivering a company's income. Most software is in back-of-the-house internal products that do various internal tasks. I have no doubt that these processes are now far easier to build.
If the new Copilot is so great, why is it completely out of the current zeitgeist when compared to Codex and Claude Code?
The fact that it's Rust should be held against the LLM, no for it. Languages with greater type safety are a massive crutch for LLMs (it's also why using an LLM to manage your NixOS install is pretty fucking awesome).
Make it port some Rust to JS, see how that goes.
And Rust isn't a super difficult language to use on a daily basis. Sure, the initial learning curve is obnoxiously steep, but it's arguably easier to use than other languages once you get past that.
The LLM crowd have this habit of equating something that they don't understand with requiring some kind of advanced skill.
Not really, your original comment was about Rust being a "massive crutch" for LLMs because it's strongly typed. In the link I posted agents are literally porting ancient binaries -- i.e. no source code, let alone the luxury of types -- to the web.
In that context, discussing whether TS or JS are strongly typed -- especially when TS is a straightforward translation to JS -- is a diversion from the main point that LLMs have already demonstrated something much, much harder.
$120k to port 430,000 loc seems quite expensive. That's dozens of cents per line of code, and equivalent to the all-in cost of a senior engineer in London for a year.
Especially expensive when you take into account the amount of that code which must have been boilerplate & meta-code in nature, meaning it should have been straightforward to move.
If you think it would have taken a single engineer one year to do this, you must not work in the industry. This would have taken multiple engineers at least a year.
> $120k ... equivalent to the all-in cost of a senior engineer in London for a year.
The most shocking thing I've read in this entire thread. Are SWE salaries really that low across the pond? That's entry level in the US. So 90k GBP a year all in, including benefits, employer-paid taxes, seat licenses, hardware, furniture, HR? So what's the after-tax takehome for someone senior enough to convert an enterprise codebase to a new language over one year?
Porting this to rust would be a multiyear, multiengineer project normally. And in fact you would almost certainly never do it, because it would be too expensive and you'd have to take engineers off of work building new features for ages.
sounds like 2x the code that no one understands, one more reason to never consider using copilot again
would be curious to know how many times "unsafe" appears in there, have seen rust devs comment on how the ais like to use unsafe to work around difficulties with memory management, like how they will sometimes subvert tests
antonmks · · focus · HN ↗
_fzslm · · focus · HN ↗
GitHub's Copilot cloud agent offering is suffering with a case of some of the worst corporate ADHD I've seen. We built a cloud agentic development pipeline on it, and it seems like almost every other week they silently change something with zero public announcement or documentation that creates real disruption for our team.
That's real, breaking changes to the platform that clearly aren't being tested/reviewed before being pushed to prod. Again with zero public announcement or documentation.
Support is useless – we're paying customers in the 4-5 figures and our tickets go unanswered.
mrheosuper · · focus · HN ↗
wannabe44 · · focus · HN ↗
Shank · · focus · HN ↗
I have no doubt that if you provide any AI system with an oracle with expected behavior that it can match that oracle with some amount of $ and tokens. I haven't seen any demonstration of anything else. Rewriting a codebase was always a challenge for humans not because of complexity, but because of the time and effort involved in matching the old version's prior behavior. It doesn't have anything to do with the serious level of work required to build something truly new from scratch in a performant way.
rfgplk · · focus · HN ↗
Shank · · focus · HN ↗
For example, any amount of software development involves fixing bugs, getting feedback from users on ideal workflows, an iteration loop of performance and bug tuning, etc. AI cannot simply create, from scratch, perfect software. Even using the SOTA models on max effort does not produce bug free software of any meaningful complexity or innovation out of the box. All that has changed is that the act of physically writing code and implementing existing patterns is now effectively a marginal cost.
Most line of business software is not e.g., delivering a company's income. Most software is in back-of-the-house internal products that do various internal tasks. I have no doubt that these processes are now far easier to build.
If the new Copilot is so great, why is it completely out of the current zeitgeist when compared to Codex and Claude Code?
zamalek · · focus · HN ↗
Make it port some Rust to JS, see how that goes.
And Rust isn't a super difficult language to use on a daily basis. Sure, the initial learning curve is obnoxiously steep, but it's arguably easier to use than other languages once you get past that.
The LLM crowd have this habit of equating something that they don't understand with requiring some kind of advanced skill.
keeda · · focus · HN ↗
<a href="https://georgzoeller.com/blog/posts/what-reverse-engineering-and-modernising-an-old-war-game-tells-us-about-the-econ/" rel="nofollow">https://georgzoeller.com/blog/posts/what-reverse-engineering...
zamalek · · focus · HN ↗
> simple C++/SDL to TypeScript/Three.js
Was that misrepresentation intentional?
keeda · · focus · HN ↗
zamalek · · focus · HN ↗
keeda · · focus · HN ↗
In that context, discussing whether TS or JS are strongly typed -- especially when TS is a straightforward translation to JS -- is a diversion from the main point that LLMs have already demonstrated something much, much harder.
zamalek · · focus · HN ↗
spaqin · · focus · HN ↗
OtherShrezzing · · focus · HN ↗
Especially expensive when you take into account the amount of that code which must have been boilerplate & meta-code in nature, meaning it should have been straightforward to move.
verdverm · · focus · HN ↗
When the Go team ported the original compiler from C to Go, they wrote a program that did ~99% of the work
<a href="https://www.youtube.com/watch?v=QIE5nV5fDwA" rel="nofollow">https://www.youtube.com/watch?v=QIE5nV5fDwA
<a href="https://go.dev/talks/2014/c2go.slide#18" rel="nofollow">https://go.dev/talks/2014/c2go.slide#18
verdverm · · focus · HN ↗
"write a program to transpile A to B" instead of "port A to B"
freeplay · · focus · HN ↗
jubilanti · · focus · HN ↗
The most shocking thing I've read in this entire thread. Are SWE salaries really that low across the pond? That's entry level in the US. So 90k GBP a year all in, including benefits, employer-paid taxes, seat licenses, hardware, furniture, HR? So what's the after-tax takehome for someone senior enough to convert an enterprise codebase to a new language over one year?
efficax · · focus · HN ↗
flohofwoe · · focus · HN ↗
verdverm · · focus · HN ↗
would be curious to know how many times "unsafe" appears in there, have seen rust devs comment on how the ais like to use unsafe to work around difficulties with memory management, like how they will sometimes subvert tests
zxor · · focus · HN ↗