Maybe there are just so many of these but at this point for vibe coded stuff like this I’m just like “who cares.” LLMs can make stuff like this now. Unless this reaches some critical mass of usage among developers why would I use it? It’s just a less maintained, less tested implementation. The more important question is “what does this teach us?” And idk the answer to that one.
Generally building something is not about "What does this teach us?" but rather "What can this be used for?". You don't build a house and as "What does this teach us?". It's honestly almost a perverse question to primarily ask for something that aims to have practical value.
The clear reason this has worth is that it's much faster than TSC.
The point is that it's clearly not just a less maintained, less tested implementation. It's 1.61x faster for one in real world apps, in some case even almost 4x faster.
I am curious why it's faster. Golang isn't that much slower than Rust, aside from the garbage collector. 4x performance improvements is much bigger than what I expected.
HN is going to be a weird place to be between people loving AI and the loss of loving tech. I don’t remember last time I watched a good tech dev video. At least the video game industry is a little bit shielded from this but soon it will be the same when we see the speed AI is advancing.
I think the difference here is that the original motivation for choosing Go over Rust was that Go was easier to port TypeScript to.
LLMs change the calculus a lot, the result seems faster, and it's possible that the TypeScript team might want to change directions. It'd be a big deal, but I bet they'll at least discuss it.
TypeScript team member here - this is impressive work, and it's honestly crazy that 3 of these ports have popped up in the last week! I'm currently AFK but we're hoping to learn more and we'll have more to say on this soon.
Language and compiler design/ implementation is very much a human task. There's lots of nuances to consider. I doubt they want agent spaghetti code in their codebase either.
I'm assuming they mean because it doesn't need a garbage collector or much of a runtime at all. You can target direct to WASM and use I guess WASI, while Go brings with it a garbage collector and so on.
Wasm is a first-class target for Rust, which produces faster and smaller Wasm binaries. My understanding is that you need to use TinyGo to reasonably target Wasm with Go.
Go having a garbage collector isn't necessarily bad, since Wasm has GC, but I think Go's GC can't easily use Wasm GC because Go has interior pointers.
I suppose my comment sort of implies this. I think the naive knee jerk reaction is that if you can spit out perfect machine level code against a specification, then logically being closer to bare metal would help with performance. However, without knowing the details of how things worked it is tough to say whether it is truly "reasonable" or not.
But more importantly, the Typescript team themselves [1] picked Golang mostly out of ergonomics and ease of porting at the time. It is becoming more increasingly more to "taste" what ergonomics means. Notably, they did not pick it because they believed it to be the fastest option. But speed was on the mind, giving way to ergonomics and ease of porting. At least, this is my read.
Was it ever a reasonable choice? At the time the choice was made the tooling ecosystem was already split between Rust and JS, and by putting TS in Go they chose to split it three ways. Why not split it 4 or 5 ways then? The pressure will always be towards less duplicated work.
The only real choice of language to build the next generation of JS tools in is JS. Anything else is a vote of no confidence in ourselves.
I think the future of this is -- get your AI agent to investigate this port for anything actually worthwhile, comparing it to the go version, and then take those good ideas and actually maybe bring them into the real compiler.
This was a lot of tokens to spend on a port. I wonder if all of the porting activity out there would be better supported by investing in really good deterministic automatic translators that do 90% of the job cheaply and delegate any decisions that have to be made back out to the AI agent?
I have to wonder if LLM reimplementations verified against years of human tests will have holes where original authors thought that tests are not necessary and common sense is enough.
I have to wonder this to preserve my ego as a human. I wonder have to this because I sure as hell am never going to go through all that code to check.
Of course they will. For about 3 days, and then it will get fixed.
At this point, for software which has an extensive test suite (or a large body of interoperable software), humans are more likely to create these kinds of gaps than the LLMs are.
LLMs have been trained to fix compile errors in a loop. Give them years of human labor worth of tests and they will fix compile errors until it works (as well as the tests can ensure). Now you have a codebase no one has read. Good luck adding new code to it.
Let's also not forget that Bun was claiming a rewrite in 11 days or whatever it was, but actually spent three months of human labor fixing hundreds of issues their rewrite introduced before shipping it as a release.
I'm curious how much unsafe this uses? Are these ports making idiomatic code or just using unsafe all over. There doesn't seem to be anything in the readme.
As much as possible mechanical (non-LLM) verification of equivalence that generates good diagnostic messages, mechanical translation steps that generate good diagnostic messages, a good memory system to reduce rework... (edit: and mechanical coverage measurement)
Sibling dead comment said it already but that's likely an estimate of what it would cost via API and in practice it was a few hundred or thousand dollars of subscription fees.
Probably zero, or even a profit. The idea that these companies are making a loss on subscriptions is an unsubstantiated HN fallacy.
On the contrary, they're probably making a small profit on subscriptions, or at least break even, and absolute bank on API pricing. Anthropic recently reported an 80% gross profit margin, for example.
Maybe there are just so many of these but at this point for vibe coded stuff like this I’m just like “who cares.” LLMs can make stuff like this now. Unless this reaches some critical mass of usage among developers why would I use it? It’s just a less maintained, less tested implementation. The more important question is “what does this teach us?” And idk the answer to that one.
Generally building something is not about "What does this teach us?" but rather "What can this be used for?". You don't build a house and as "What does this teach us?". It's honestly almost a perverse question to primarily ask for something that aims to have practical value.
The clear reason this has worth is that it's much faster than TSC.
That's why the commenter said
> It’s just a less maintained, less tested implementation
Then they asked if it teaches something because it is a risky utility to them. You're trying to make it sound a lot weirder.
The point is that it's clearly not just a less maintained, less tested implementation. It's 1.61x faster for one in real world apps, in some case even almost 4x faster.
I am curious why it's faster. Golang isn't that much slower than Rust, aside from the garbage collector. 4x performance improvements is much bigger than what I expected.
If that was your point, why did you spend a whole paragraph saying "teach us? What a perverse question."
HN is going to be a weird place to be between people loving AI and the loss of loving tech. I don’t remember last time I watched a good tech dev video. At least the video game industry is a little bit shielded from this but soon it will be the same when we see the speed AI is advancing.
No more joy crafting things as a dev…!
I think the difference here is that the original motivation for choosing Go over Rust was that Go was easier to port TypeScript to.
LLMs change the calculus a lot, the result seems faster, and it's possible that the TypeScript team might want to change directions. It'd be a big deal, but I bet they'll at least discuss it.
It teaches us the Rust community continues to be relentless in their efforts to rewrite virtually everything in Rust.
TypeScript team member here - this is impressive work, and it's honestly crazy that 3 of these ports have popped up in the last week! I'm currently AFK but we're hoping to learn more and we'll have more to say on this soon.
Kudos for keeping up! Golang seemed like a very reasonable choice when you ported there originally but the world is changing _fast_.
Why do you think Golang is no longer a reasonable choice?
Presumably because Rust is more suitable than Go in agentic coding? (I'm not sure, but that seems the purported answer.)
Language and compiler design/ implementation is very much a human task. There's lots of nuances to consider. I doubt they want agent spaghetti code in their codebase either.
Rust is better at targeting WebAssembly
Why?
I think the main advantage is size. Rust doesn't need to include the runtime.
I'm assuming they mean because it doesn't need a garbage collector or much of a runtime at all. You can target direct to WASM and use I guess WASI, while Go brings with it a garbage collector and so on.
Wasm is a first-class target for Rust, which produces faster and smaller Wasm binaries. My understanding is that you need to use TinyGo to reasonably target Wasm with Go.
Go having a garbage collector isn't necessarily bad, since Wasm has GC, but I think Go's GC can't easily use Wasm GC because Go has interior pointers.
why would that be important? Having a typescript compiler in wasm seems like a pretty niche need.
I suppose my comment sort of implies this. I think the naive knee jerk reaction is that if you can spit out perfect machine level code against a specification, then logically being closer to bare metal would help with performance. However, without knowing the details of how things worked it is tough to say whether it is truly "reasonable" or not.
But more importantly, the Typescript team themselves [1] picked Golang mostly out of ergonomics and ease of porting at the time. It is becoming more increasingly more to "taste" what ergonomics means. Notably, they did not pick it because they believed it to be the fastest option. But speed was on the mind, giving way to ergonomics and ease of porting. At least, this is my read.
[1] https://github.com/microsoft/typescript-go/discussions/411
The author of esbuild used Rust and later switched to Go. He describes some of his experience here:
https://news.ycombinator.com/item?id=22336284
It is one person and one project, but I found it interesting to read about his experience.
I like Go, but I probably would have tried Rust first because I want pattern matching when implementing languages.
Was it ever a reasonable choice? At the time the choice was made the tooling ecosystem was already split between Rust and JS, and by putting TS in Go they chose to split it three ways. Why not split it 4 or 5 ways then? The pressure will always be towards less duplicated work.
The only real choice of language to build the next generation of JS tools in is JS. Anything else is a vote of no confidence in ourselves.
Rust is more close to metal. No GC
I think the future of this is -- get your AI agent to investigate this port for anything actually worthwhile, comparing it to the go version, and then take those good ideas and actually maybe bring them into the real compiler.
Maybe. Who knows, it's all changing so fast!
This was a lot of tokens to spend on a port. I wonder if all of the porting activity out there would be better supported by investing in really good deterministic automatic translators that do 90% of the job cheaply and delegate any decisions that have to be made back out to the AI agent?
I have to wonder if LLM reimplementations verified against years of human tests will have holes where original authors thought that tests are not necessary and common sense is enough.
I have to wonder this to preserve my ego as a human. I wonder have to this because I sure as hell am never going to go through all that code to check.
Of course they will. For about 3 days, and then it will get fixed.
At this point, for software which has an extensive test suite (or a large body of interoperable software), humans are more likely to create these kinds of gaps than the LLMs are.
I wish Anthropic/OpenAI would give me free tokens so I could make random things like this
I already pay for subs on both but the tokens are already spoken for with other projects
In the real world project section, compile times vs tsc7 were 1-3s less. Sometimes the percentages are far more impressive than absolutes.
LLMs have been trained to fix compile errors in a loop. Give them years of human labor worth of tests and they will fix compile errors until it works (as well as the tests can ensure). Now you have a codebase no one has read. Good luck adding new code to it.
Let's also not forget that Bun was claiming a rewrite in 11 days or whatever it was, but actually spent three months of human labor fixing hundreds of issues their rewrite introduced before shipping it as a release.
This post should be titled “Rust port of Go rewrite of Typescript compiler”
I'm curious how much unsafe this uses? Are these ports making idiomatic code or just using unsafe all over. There doesn't seem to be anything in the readme.
Have a look yourself: https://github.com/search?q=repo%3Apingdotgg%2Fts-rust+unsaf...
Doesn't look like any on skim, also looks like an explicit goal was to avoid unsafe code: https://github.com/pingdotgg/ts-rust/blob/ad8f2746ea85a6354b...
Are there any specific harnesses or techniques to aid in porting stuff to Rust? Specialized in terms of token efficiency
As much as possible mechanical (non-LLM) verification of equivalence that generates good diagnostic messages, mechanical translation steps that generate good diagnostic messages, a good memory system to reduce rework... (edit: and mechanical coverage measurement)
Wait - you spent north of $400,000?
$420,000 worth of tokens, though I'm pretty sure he used subs.
> I did over $400,000 in API priced tokens
i'd bet this is a few subscriptions over a few months rather than paying directly for tokens.
Sibling dead comment said it already but that's likely an estimate of what it would cost via API and in practice it was a few hundred or thousand dollars of subscription fees.
Most of it was wasted on OpenAI tokens. It actually cost them $24k USD according to the github description.
So, you could do it for a couple hundred bucks using DeepSeek.
Assuming he used $400,000 in tokens, but used subs
I wonder how much AI companies lost on this?
Edit: not that I’m worried about them, I’m just curious
> I wonder how much AI companies lost on this?
Probably zero, or even a profit. The idea that these companies are making a loss on subscriptions is an unsubstantiated HN fallacy.
On the contrary, they're probably making a small profit on subscriptions, or at least break even, and absolute bank on API pricing. Anthropic recently reported an 80% gross profit margin, for example.
https://www.reuters.com/business/retail-consumer/anthropic-t...
Profitable, if you just ignore how much money they spend
Excited for their IPO just to put this to bed, one way or another.
What are “subs”?
Subscription
So you pay $20/mo, let or run for a long time, then claim you used the equivalent of $1/2 million?
People love to flex by using the API costs for their subscription tokens.
I personally find it ridiculous. The cost is what you paid, not what someone else could have paid. Markets and all that.
It would be like using spot instances on AWS but flexing by boasting about how much on-demand $$ compute you used.
In this case, I think they are just giving you an idea of what it cost to do this. They aren't saying it's prescriptive
Except.. It doesn't really give you an idea what it cost? That's not what it cost. How much did it actually cost? Who knows!
It's also TheoGG sooooo.. Those influencer instincts tho.
No that's the theoretical token value cost based on chaining multiple 20x subs.
I wonder how that cost compares to paying a human programmer to produce the same end result.
I honestly have no idea what the future of tech will look like at this point. Too much has changed.
Is this going to be a serious project? No.
Is this going to be maintained? Nope
Nevertheless this and many others are showing what is possible. Much akin to how someone ports doom onto a microwave.
We'll look back at this time with great fondness when we collectively discovered a whole new gear.
Why does it seem like this is falling off the front page really fast? There's older posts with less points that are way higher.
I really appreciate this convention, thank you.
imagine if they had the willingness to re-write it for human consumption. might a well delete it