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.
If DeepSeek was smart enough. There's a huge risk that it isn't since the only model that ultimately succeeded was Opus 5.5 (sol and astra were tried before).
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.
It might, but also might not. I would imagine the economics are genuinely very tangled up even before you start obfuscating it - it’s very hard to fairly allocate fixed costs between training and inference.
I think a clearer picture would be from inference-only orgs.
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.
With the caveat that Go cannot use WASM GC, because it is still a MVP and it does not support internal pointers, so languages like D, Go and C# have to keep shipping their own implementations.
Theo is making a new twist on the idea of IDE which hosts the application itself. I'm sure there's going to be a video about it soon. But the idea is to embed the whole compilation and type-check in wasm in the browser which then runs the app immediately, as the agents edit the code.
It's extremely useful if your distribution platform is the web. However, I find it much more valuable as a type checker than a compiler. I use TypeScript extensively (in several projects) for defining schemas types.
For example, in the Breaka Club (https://breaka.club/) editor, which is not presently exposed to kids yet, we define behaviors for characters, props, mosaics (terrain tiles) and items in JSON. But the JSON has type checking and real-time completion as you type. Not naive property auto-suggestion, we have effect types and they're context aware in that you can refer to targets introduced higher in parent constructs of the JSON — and they're fully type checked. If you refer to a target that does not exist in a context, it won't validate and you cannot save the schema.
We use tsgo for development, but the editor (runtime schema validation) is presently stuck on TypeScript 6 because there's no WASM support.
Now, is it nutty that we're using TypeScript for JSON validation? A little. But it's extremely powerful. We're going far beyond what's capable with Zod or ArkType.
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.
Very interesting. With rust's ocaml heritage, I'd imagine a straight port from typescript would be simpler and more idiomatic than a port to go. I guess not.
The notable thing that these LLM-generated ports aren't doing is _rewriting in Go_. TypeScript 7 is a lot faster than the JS/TS-based version 6, but memory use is a major bottleneck.
However, it mostly represents a mechanical port of the old codebase to Go. What I haven't seen anyone do is try a true rewrite in Go optimized for performance (whilst keeping a strong emphasis on readability).
> then logically being closer to bare metal would help with performance
Once you move beyond interpreters, performance is mostly a property of how much effort you want to put into profiling and optimization, not any specific properties of a programming language (YMMV of course).
I agree, but certainly language constraints or features make analysis easier (and some analysis which was previously impossible now suddenly is) which in turn unlocks/enables a whole world of optimisations the compiler can do for you!
> you can spit out perfect machine level code against a specification
Typescript team explicitly mentioned the lack of Typescript specification as one of the reasons to choose Go. Typescript as the language is defined currently by its compiler which was Javascript based. Go port is as close to it as possible while Rust would be harder to reach fully identical behavior.
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.
It's ok for a language (JS in this instance) to be good in a domain but not good in all domains. Pulling a language in every direction forces it to make compromises that hurt its applicability in specific areas.
So for context my beef with them is that they didn't try. I think you're being very "hand wavey" about why JS isn't a good host language, just as they were.
If the argument is "we need to show a 10x boost in raw throughput" then I think we first need to have an argument about why throughput is the right metric as a target for optimization. Throughput is the critical performance measure of a batch processing architecture. IDE's, like web UIs, "feel fast" when they're responsive, which is to say when they can start giving the user access to useful output (and interaction) at the soonest moment the program could possibly be ready to do so. In web perf we might measure this as INP: time from Interaction to Next Paint.
JS won't be winning prizes for throughput, no, but if we completed the move away from a batch processing mindset to an incremental recomputation mindset, and at the same time switched to measuring responsiveness metrics like INP, suddenly the perf characteristics of JS seem a lot more helpful. It's the closest language to the DOM, so when your IDE's interface is built on web technology you'll optimize INP by keeping the data layer in JS: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...
There's an even stronger reason than the DOM though to see JS as the "native" layer for perf: plugins. An IDE's selling point is integration, and users want to extend their IDEs by writing Javascript code. Like it or not, JS is the most natural and highly-performant native kernel language for a system of JS plugins.
You may have missed the project history, this _was_ implemented in JS previously. I don't think they were interested in porting it back to a language it was originally written in.
I know my history just fine. What I'm saying is: you can't say that it means that JS is a bad language to write tools in. That's would be like saying "our design had bad perf and it was implemented as JS, therefore no design implemented in JS can have good perf". I hope we agree this would be a faulty deduction, or at least an unfounded one.
The case against JS was specific: data marshalling neglects the Web Workers performance boost for an "embarrassingly parallelizable" project. And it was stated clearly.
It depends on the workload. ARC can be more expensive than tracing GC, especially with heavily shared objects.
But my main point was that the presence of a GC has nothing to do with how close a language is to the metal. Memory management strategy and low-level capabilities are two separate things.
Rust could just as well have an optional tracing GC for shared ownership instead of ARC, potentially improving performance rather than reducing it. Having a GC doesn't inherently make a language slower.
Yeah but let's be honest; GC languages (Go, Java, C#) usually are slower than systems languages. Systems languages just give you more, low level control over the computer from within your program. You can use that control to improve performance. Eg, you can control data locality, memory access patterns, the emitted assembler, and way more stuff.
Of course you're right - if you misuse arc, you can make your program slow. So don't misuse arc then. Rust gives you lots of options for structuring memory. If you choose badly, that's on you.
Not everything has to be ARC though and arenas are strictly better than GCs lacking synchronization issues for allocation and not needing any scanning for deallocation.
GC doesn’t affect performance (at least visibly), memory allocations on critical paths do. Moreover, Rust ARC may cause memory fragmentation and perform worse than a GC.
Writing Rust, Zig, or Go, you would still control memory manually, where it matters.
It does have an impact. Discord blogged about unavoidable GC delays in go that occurred because go needed to traverse live memory, their only option (in go) for reducing that pause was to reduce the size of their data set.
GC absolutely has performance costs, even with minimal allocations, because tracing collectors must scan live objects. This is exactly what this post says. Don't know if its really improved over time in real world cases.
I'm doing this right now with Codex. It's currently working on porting the Binder.
7-11 phases to go and so far it looks like it might only cost $100. I'm focusing on efficient execution strategy minimizing token in/out, turns, and rework.
Will prob post up something interesting when it's done.
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.
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.
People were doing silly things with expensive MacBooks all along. It is akin to a non-techie parent saying "what are you doing with your expensive computer ..."
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.
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)
It is beginning to look like the future is treating Rust as an optimization pass. Write your program in a higher-level language like Typescript, Go, Python, etc. and then have LLMs compile that to Rust.
Not really, the future are natural languages, with some markdown files for formal specification, yaml or whatever, and then Assembly gets generated directly.
3 GLs are going to slowly fade out as LLM tooling improves, and coding looks increasingly as envisioned by 4 GLs advocates.
Sounds awful, natural language sucks for describing complex problems and relationships. That's why people have historically reached for diagrams and pseudo code.
Given the rate of progress, it's hard to argue why this couldn't be a reality.
If in the future Taalas-type chips with baked in frontier models are commonplace, this should be quite different price-wise from what we have now.
It's a bit dizzying to imagine that LLMs might even be able operate at speeds of chatjimmy.ai, but we already have working tech that does exactly this (albeit with less intelligence/capabilities).
Theoretically the LLMs could go straight to machine code. No need for any intermediate language. However, the HN stories have made it clear that LLMs are not great at going directly to machine code or Rust. Rust is, time and time again, is being used used as an optimization intermediary. If LLMs were better to target it directly they wouldn't be reading report after report about translating to it from another language.
Yesterday I asked Claude to make a RISCV emulator like qemu in x86 assembler. It runs about 5x slower than qemu. That's a pure interpreter vs one of the best JITs. Qemu can run many more instructions though.
We have to accept that those of us that survive the AI layoff wave and want to work in IT, will have to work as technical architects, solution analysts, requirements management, or move into management roles.
Coding as we knew it will be left to weekends and retro-computing handcraft fairs.
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 don't see at all that this is stifling love of tech. Sure if you liked to engage in language wars or vim vs emacs or tabs vs spaces then yes that's over. But tech as we know it is currently exploding, a ton of stuff that simply was not practically possible before is now possible.
Give us some examples of things that were not practically possible. Things are practically possible if the time or money is wisely spent, even if it takes a human a bit longer.
Money and time are precisely the point. Things are not practically possible of a X would cost 100K to develop and it's worth was 30K. But now that it costs 2K to develop it is suddenly practically possible.
2. The abundance of game decomps and recomps becoming available. Literally dozens of example in this space.
3. Reverse engineering of obscure software. A ton of oppertunities lie here.
4. As this posts indicate, severely accelerating existing software by re-writing it in language that are not terrible for performance.
5. Analyzing large volumes of unstructured information.
6. Creating one-off engineering and scientific tools.
7. Beating essentially all traditional Linux distribution, see Omarchy.
8. A personal example: I'm remaking the engine of an old game commercial game in rust.
I'm honestly a bit taken aback that this question is even asked. The volume of software is exploding and the power of the individual has increased a hundredfold.
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.
Given the Typescript compiler rewrites that keep popping up, Next.js has one, this is another one, Angular just announced they are also going with theirs, eventually there will some community pressure on how the team will proceed.
Note there is already a feedback post from them (currently top one), that they will need to react to this.
Do we know why? Is there some hole the official one isn’t filling? Seems like having 10 different compiler implementations would be a portability nightmare. Now I can’t guarantee my typescript is going to run the same on node/angular/whatever
Yes. This has nothing to do with people trying to rewrite things in Rust for fun. It's a part of his development project that I'm sure will get a video in the future.
Would gold be valuable if anyone could create it at will? Sure, a few people would like the colour and the way it shines, but most would be indifferent. A lot of these things were cool because we knew they were difficult and had technical challenges to overcome. Now it's easy, I just don't care.
In this case the idea here is ‘rewrite tsc in Rust” not exactly earth shattering. If somebody hand wrote that, then they could have gleaned some new insights about Rust or Typescript or something which could be interesting, but in this case they just had an LLM do it and didn’t even read the code. So it’s a big who cares. If it gets adopted by the official compiler team, then I’ll be interested. But right now you would be an idiot to use this for anything mission critical.
When people post AI projects with genuinely new/interesting ideas, then I am interested.
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.
Interestingly, your whole comment implicitly has the answer to this. In the future you don't add code or read it, you only add test cases and have the loops work on covering the new case.
I don't know that I agree, especially with LLMs as they are right now.
Maintainability isn't just for humans. An LLM working in an unmaintainable codebase has the same problems we do. It doesn't necessarily follow that if your code can pass your tests today then it will be able to pass the tests of tomorrow. I'm in healthcare. Regulations and payor rules change constantly. I don't know what tomorrow will bring, but I do know that the code I have an LLM generate tends to focus on the here and now (at the expense of the future). Sometimes that's okay, though. I don't know much about writing a compiler, so it could theoretically work.
This is by no means an anti-AI post (I use the hell out of these tools). But I can still see the cracks in them.
The existing test cases were created based on understanding the code. Creating good tests that cover every case you care about without understanding the code is not possible.
These big ports we are hearing about are of projects with hundreds (prob thousands) of unit tests. Not only are the models typically trained with the original code bases in their dataset, but the test suites themselves have project architecture encoded in them..
Ultimately there isn't enough information on how to most effectively maintain and evolve large, complex software with LLMs yet. We aren't even a year out from Opus 4.5.
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?
What a waste of power... $424.000 of API priced tokens amounts to how many kWh burned? And how would you trust this to build your code?
Motivations says it all:
Motivations
Test model capabilities
Make a fast TypeScript type checker
Make a ts checker that can work in WASM with high performance
Memes
Do you read the test suite of all the programs you run? I trust software because the authors have shown themselves to be competent and trustworthy. I expect authors to understand what they are doing, not just bashing into the guardrails until they get something that passes all the tests.
An LLM has reimplemented a 2 times faster version of a program developed by a team of dozens of brilliant engineers led by few of the biggest experts in compilers and programming languages in the world.
While maintaining 100% test coverage and so far compiling every single project that the original compiler did.
If your takeaway here is "yeah, but the other one has been checked by dozens of paid devs and an entire community", and still those dozens of devs with the backing of thousands of contributors could not make a compiler faster I can't buy say: "maybe we humans aren't as good as writing code as we thought and LLMs are exposing us".
There are companies that spend the equivalent of that in a single day on tokens. Lets not wage war against one person here.
Its the equivalent of telling individual people they are the problem when it comes to leaving their living room lights on when not in the room or they don't recycle all their stuff correctly when companies/corporations have orders of magnitude more waste.
>Spent over $400,000 in API priced tokens with GPT-5.6 Sol and GPT 6 Astra. They wrote over 1.3m lines of Rust over multiple months of /goal loops and never got past like 84% compat.
Then they let Claude code lose on the problem:
> I figured it'd be fun to throw Opus 5.5 at this. It had a working v0 in 10 hours. I assumed it kept using the code the Codex models wrote. I was wrong. Opus 5.5 started from scratch. It got further than Astra in 1/10th the time.
In the warnings from README.md
> Also worth mentioning: I've never read a line of this code.
Looks like this is a company’s org which heavily relies on AI. Probably “the cost of doing business” and to see just what can be done with the new model.
He didn’t spend that much either. That’s the equivalent API cost using his $200/month subscription. It took less than a day so I guess it cost about $7 in actual money.
Ok, that makes more sense. If the other comments are correct in saying this was done using a $200/mo personal subscription, I get this is more of a “what is possible, and how much would it cost without subsidized pricing” type of experiment. Thank you for clarifying on that.
What the hell is "theoretical money"? It sounds like either OpenAI took the $400k hit, or their API pricing is utterly bonkers and therefore completely pointless to quote. It would be like me saying my car is worth $400k in theoretical money because, yeah, I'd totally sell it to you for $400k.
I've been rinsing Opus 5.5 and I've been unable to get over 20% of my plan usage, it seems to use a tiny fraction of the usage that Opus4.8 or 5.0 used.
I don't know if it's an accounting trick or genuinely less usage, but since 5.5 I've not had to think about limits at all.
> Spent over $400,000 in API priced tokens with GPT-5.6 Sol and GPT 6 Astra
Tangent here, but I think this bit is super interesting!
You could viably hire someone to do this work for that kind of money - I think the interesting thing is that substantially less interested/experimenting engineers would consider paying for a human to do this work, than would happily chuck a big amount of money into an LLM.
I don't have any suggestion about why that exists, but it's a strange and interesting contract.
To be fair, NSF grants for pure mathematicians were never as substantial as for applied sciences, but they would routinely reach 500k–1M territory. That's the amount going to a single proposal, and grant panels in, say, analysis would definitely spend millions per application season. NSF funding data is public and can be looked up.
I'm using past tense because iirc NSF has recently reduced their funding volumes, although I'm not following the situation very closely.
NSF by itself contributes $200-300M a year towards math grants. Universities spend a billion+. Add corporate funding and other sources (DoD, other government agencies, private foundations) and you’re easily looking at a few billion dollars a year just in the US going to mathematicians.
I found the whole section super interesting... I'll copy it here:
I used a lot of OpenAI models to try and complete this port. In total I did over $400,000 in API priced tokens with GPT-5.6 Sol and GPT 6 Astra. They wrote over 1.3m lines of Rust over multiple months of /goal loops and never got past like 84% compat.
When I saw how little my Claude Code limits were burning, I figured it'd be fun to throw Opus 5.5 at this. It had a working v0 in 10 hours.
I assumed it kept using the code the Codex models wrote. I was wrong. Opus 5.5 started from scratch. It got further than Astra in 1/10th the time.
I let it keep going, and it definitely did. Total token spend was ~$24,047 of API spend over 2 weeks. I was using my Claude accounts, and it worked out to somewhere between 925% and 983% of my $200 plan weekly limits.
Expensive, for sure, but not that bad considering how much work has went into typescript-go.
> I assumed it kept using the code the Codex models wrote. I was wrong. Opus 5.5 started from scratch. It got further than Astra in 1/10th the time.
Ouch, that is brutal and honestly, quite embarrassing but confirms what I have been seeing for a while. Personally, I find output from current OpenAI models still very hard to parse (though it has gotten better vs the pre-trains from both labs in mid/late 2025), thus hard to truly understand, verify and get comfortable maintaining vs current Anthropic models. I do occasionally see a higher ceiling in well scoped tasks with OpenAI models at the cost of (frequently) deviating from the original prompt in (sometimes) very destructive ways.
Could be that this hard-to-read output doesn't just go over my limited capacity/skills but with current models can become simply impossible to untangle beyond a certain size even when one has (essentially) infinite resources via multiple subs and different models.
Would also work with my suspicions for why OpenClaw (mainly build with Opus 4.5 and its post-trains) has been this hard to truly "fix", requiring highly paid Nvidia engineers, multiple months, (literally) infinite resources from OpenAI including access to internal models and yet still holds records for CVEs. Heck, another one was found just 7 days ago after what I'd argue was one of the most extensive hardening sessions any piece of software has ever undergone.
Makes my (multiple) decisions to start from scratch more than once on a major reworking of the existing tabbing interface in Firefox a bit less painful. Learned with each, found gaps in my knowledge, thanked the amazing docs the Firefox devs have been maintaining for decades and while starting from 0 was painful, getting back to MVP is easier than ever. When I hit a point were I was starting to struggle to truly parse additions a model was making to the patches applied to Firefox source code (even if they worked), I always found that pushing even slightly beyond that would incur painful, but hard to notice regressions, introduce major DB maintenance burdens as some models struggle to understand that in development regressions and incompatibility are acceptable and schema transitions aren't needed pre-release (still a case with GPT-6.1 Sol, less so post Fable for Anthropic), make me uncomfortable concerning privacy/security/data loss prevention (especially as I have seen Fable 5 cut some privacy/proper data removal corners in simple CRUD) and simply take away my control about the implementation. Wouldn't feel right to release something in that state, what I have now is fully understandable and thus could be maintained even without models.
Still expecting bugs of course, massively dreading security findings or even worse, possible data loss given browsers handle some of our most important personal+professional data and will surely have taken some embarrassing approaches that might have a much more performant solutions when implementing an infinite canvas of webpages, but still, rather that then also knowing I wouldn't even know where to start understanding a feature.
More so if, like with ts-rust, even (nearly) infinite tokens couldn't get me unstuck.
I think it's hard to know what to make of that. Observations with little insight.
Maybe it just needed to be prompted differently? Maybe Astra starting from scratch could have done it? Maybe Opus was somehow trained more on the Golang implementation.
Could be. Feel at 6k commits there is a lot to be learned here, might be useful to compare code quality, approach taken by each model and assess whether what Astra created was truly unsalvageable.
Prompting wise, would be interesting to know how much steering truly happened across the project, if one wanted the model to truly work without detailed input, there isn't much that could be done to improve. How much was lined out and set I'd love to know, don't see it anywhere in the commits though, just the AGENTS.md and a few other docs files. "Port TS compiler, checker and LSP to Rust, never ask any questions" would be pretty funny though.
> Ouch, that is brutal and honestly, quite embarrassing but confirms what I have been seeing for a while.
What's most interesting is that Opus wasn't told to toss out the Codex crap. It decided to do that on its own. Which might mean that LLMs are actually getting a reasonable taste.
I've seen on youtube that some guy implemnted game engine with Astra and Claude. Astra wasn't really given fair chance because it didn't decide to work as long as Claude and the guy didn't force it. But still, scripting code within the engine that came from Astra was chaotic, messy, piling up things, but the code that Claude made looked downright pleasant.
This is Theo's project, and he has been very transparent about how he is only doing these things because api prices are heavily subsidized by subscription pricing. The reason people aren't willing to pay 400k to an engineer to do this work is because they aren't paying the AI this much.
I don't think I've seen an enterprise paying API prices doing these sorts of rewrites, and honestly, I think until that happens I will remain skeptical about LLM AI's viability as a profitable business.
He's not paying that much in practice. But even if he did, you couldn't hire 3 engineers (I'm assuming you'd get 3x 133k each) that could do this work in anywhere close to this amount of time. It would be a multi-month long project. So "to do this work" is not really comparable.
The most interesting part if I got it right is that he got 400k of free GPT api to test and publicly concluded that 10 hours of Claude Code subscription is better. For anyone that knows this influencer, he's always been a paid shiller for Anthropic. It's funny that OpenAI still reached for him if that's true.
This officially proves how great the Go code is! I mean: You have easiness and friendliness and high level language of Go for only 50%~70% slower performance. I always thought what happens if they port to Rust? Will it also become an order of magnitude faster? Turns out it really is not worth the cost. Go is perhaps just the best language.
Go is not higher level. If anything I would consider Rust higher on the abstraction ladder than Go. Or rather it's perhaps better to say that Rust is higher level but can go down to a lower level than Go.
I both agree with you and still think my initial idea was correct, and it means that I have expressed it very badly. What I meant by higher order was all the little niceties Go has that becomes a nightmare in Rust, the memory management, simple language; I mean just think about working with strings in Go vs Rust. The amount of boiler plate stuff always gives me a headache in Rust. But you're right, the map to C and C++ and go is orders of magnitude less developed in that terms.
Reminds me of this LLM port of Liquid template language to Go, where it decides to emulate Ruby duck typing by making everything an interface and constantly casting it to different types: https://github.com/Notifuse/liquidgo
ingen0s | 21 hours ago
colomo | 21 hours ago
spense | 21 hours ago
i'd bet this is a few subscriptions over a few months rather than paying directly for tokens.
TiredOfLife | 9 hours ago
hedgehog | 21 hours ago
JacobAsmuth | 21 hours ago
LeFantome | 19 hours ago
scotty79 | 4 hours ago
JacobAsmuth | 2 hours ago
sghiassy | 21 hours ago
I wonder how much AI companies lost on this?
Edit: not that I’m worried about them, I’m just curious
esperent | 20 hours ago
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...
adrianvincent | 20 hours ago
janalsncm | 20 hours ago
rich_sasha | 16 hours ago
I think a clearer picture would be from inference-only orgs.
MBCook | 20 hours ago
sghiassy | 20 hours ago
MBCook | 20 hours ago
scotty79 | 9 hours ago
sghiassy | 8 hours ago
Then take the minutes you used and compare what it would’ve cost, if you paid by the minute
Rapzid | 20 hours ago
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.
Capricorn2481 | 20 hours ago
Rapzid | 19 hours ago
It's also TheoGG sooooo.. Those influencer instincts tho.
aizk | 20 hours ago
woozlewuzzle | 19 hours ago
pebal | 16 hours ago
fwlr | 21 hours ago
sitzkrieg | 19 hours ago
DanRosenwasser | 21 hours ago
vaughands | 21 hours ago
zdragnar | 21 hours ago
lifthrasiir | 20 hours ago
lifeisloving | 20 hours ago
true_religion | 10 hours ago
spankalee | 20 hours ago
teki_one | 20 hours ago
0x696C6961 | 20 hours ago
cmrdporcupine | 20 hours ago
spankalee | 20 hours ago
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.
win311fwg | 15 hours ago
However, it has a relatively large runtime, so TinyGo is often preferred when bundle size needs to be small.
pjmlp | 8 hours ago
cowsandmilk | 20 hours ago
viraptor | 17 hours ago
pjmlp | 13 hours ago
- https://www.typescriptlang.org
- https://code.visualstudio.com/docs/remote/vscode-web
Benjamin_Dobell | 12 hours ago
For example, in the Breaka Club (https://breaka.club/) editor, which is not presently exposed to kids yet, we define behaviors for characters, props, mosaics (terrain tiles) and items in JSON. But the JSON has type checking and real-time completion as you type. Not naive property auto-suggestion, we have effect types and they're context aware in that you can refer to targets introduced higher in parent constructs of the JSON — and they're fully type checked. If you refer to a target that does not exist in a context, it won't validate and you cannot save the schema.
We use tsgo for development, but the editor (runtime schema validation) is presently stuck on TypeScript 6 because there's no WASM support.
Now, is it nutty that we're using TypeScript for JSON validation? A little. But it's extremely powerful. We're going far beyond what's capable with Zod or ArkType.
tcfhgj | 11 hours ago
vaughands | 20 hours ago
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
dunham | 20 hours ago
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.
e12e | 11 hours ago
jitl | 9 hours ago
pjmlp | 8 hours ago
Notorious examples, the recent Github Copilot runtime, and the Microsoft 365 microservices.
e12e | 4 hours ago
The "shape" of the code would be different?
jitl | 3 hours ago
andrewingram | 12 hours ago
However, it mostly represents a mechanical port of the old codebase to Go. What I haven't seen anyone do is try a true rewrite in Go optimized for performance (whilst keeping a strong emphasis on readability).
flohofwoe | 8 hours ago
Once you move beyond interpreters, performance is mostly a property of how much effort you want to put into profiling and optimization, not any specific properties of a programming language (YMMV of course).
spoiler | 7 hours ago
lr1970 | an hour ago
Typescript team explicitly mentioned the lack of Typescript specification as one of the reasons to choose Go. Typescript as the language is defined currently by its compiler which was Javascript based. Go port is as close to it as possible while Rust would be harder to reach fully identical behavior.
conartist6 | 20 hours ago
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.
dwattttt | 13 hours ago
conartist6 | 10 hours ago
If you wanted to point to their evidence you couldn't because they don't have any.
dwattttt | 10 hours ago
I would not want a core internet router or a kernel to be implemented in JS. But I am happy it is used elsewhere.
conartist6 | 9 hours ago
If the argument is that it's not fast enough, JS is actually quite fast: https://mrale.ph/blog/2018-02-03-maybe-you-dont-need-rust-to...
If the argument is "we need to show a 10x boost in raw throughput" then I think we first need to have an argument about why throughput is the right metric as a target for optimization. Throughput is the critical performance measure of a batch processing architecture. IDE's, like web UIs, "feel fast" when they're responsive, which is to say when they can start giving the user access to useful output (and interaction) at the soonest moment the program could possibly be ready to do so. In web perf we might measure this as INP: time from Interaction to Next Paint.
JS won't be winning prizes for throughput, no, but if we completed the move away from a batch processing mindset to an incremental recomputation mindset, and at the same time switched to measuring responsiveness metrics like INP, suddenly the perf characteristics of JS seem a lot more helpful. It's the closest language to the DOM, so when your IDE's interface is built on web technology you'll optimize INP by keeping the data layer in JS: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...
There's an even stronger reason than the DOM though to see JS as the "native" layer for perf: plugins. An IDE's selling point is integration, and users want to extend their IDEs by writing Javascript code. Like it or not, JS is the most natural and highly-performant native kernel language for a system of JS plugins.
dwattttt | 8 hours ago
conartist6 | 8 hours ago
Rapzid | 10 hours ago
mordv | 8 hours ago
sreekanth850 | 20 hours ago
pebal | 17 hours ago
saagarjha | 14 hours ago
pebal | 14 hours ago
But my main point was that the presence of a GC has nothing to do with how close a language is to the metal. Memory management strategy and low-level capabilities are two separate things.
sreekanth850 | 12 hours ago
pebal | 11 hours ago
josephg | 10 hours ago
Yeah but let's be honest; GC languages (Go, Java, C#) usually are slower than systems languages. Systems languages just give you more, low level control over the computer from within your program. You can use that control to improve performance. Eg, you can control data locality, memory access patterns, the emitted assembler, and way more stuff.
Of course you're right - if you misuse arc, you can make your program slow. So don't misuse arc then. Rust gives you lots of options for structuring memory. If you choose badly, that's on you.
legulere | 8 hours ago
aka-rider | 14 hours ago
Writing Rust, Zig, or Go, you would still control memory manually, where it matters.
dwattttt | 13 hours ago
legulere | 9 hours ago
sreekanth850 | 13 hours ago
GC absolutely has performance costs, even with minimal allocations, because tracing collectors must scan live objects. This is exactly what this post says. Don't know if its really improved over time in real world cases.
galkk | 18 hours ago
Rapzid | 10 hours ago
I wonder how few tokens it could be done in. Might be relatively easy work compared to Rust.
Give it the goal of native AOT.. Have it profile and optimize after it gets a working version...
gzapp | 5 hours ago
7-11 phases to go and so far it looks like it might only cost $100. I'm focusing on efficient execution strategy minimizing token in/out, turns, and rework.
Will prob post up something interesting when it's done.
aizk | 20 hours ago
Maybe. Who knows, it's all changing so fast!
elcritch | 21 hours ago
dbalatero | 21 hours ago
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...
bitpush | 21 hours ago
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.
BigJono | 18 hours ago
More unserious and unmaintained projects at 400k a pop. Sick.
bitpush | 3 hours ago
pvillano | 20 hours ago
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.
LeFantome | 19 hours ago
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.
ghboo0927 | 8 hours ago
catlifeonmars | 20 hours ago
fiatpandas | 20 hours ago
hedgehog | 20 hours ago
Gigachad | 20 hours ago
win311fwg | 14 hours ago
pjmlp | 13 hours ago
3 GLs are going to slowly fade out as LLM tooling improves, and coding looks increasingly as envisioned by 4 GLs advocates.
NewLogic | 13 hours ago
chasd00 | 10 hours ago
pjmlp | 10 hours ago
These are not what-ifs, this is an active area of research currently,
"CGO 2022 Keynote: Compiler 2.0"
https://www.youtube.com/watch?v=w_sX9aZoZxg
"Machine-Generated, Machine-Checked Proofs for a Verified Compiler"
https://www.youtube.com/watch?v=Dmt0h99iOmM
Gigachad | 11 hours ago
rpozarickij | 11 hours ago
If in the future Taalas-type chips with baked in frontier models are commonplace, this should be quite different price-wise from what we have now.
It's a bit dizzying to imagine that LLMs might even be able operate at speeds of chatjimmy.ai, but we already have working tech that does exactly this (albeit with less intelligence/capabilities).
chasd00 | 10 hours ago
win311fwg | 9 hours ago
childintime | 7 hours ago
pjmlp | 8 hours ago
Coding as we knew it will be left to weekends and retro-computing handcraft fairs.
yoyohello13 | 20 hours ago
rowanG077 | 20 hours ago
The clear reason this has worth is that it's much faster than TSC.
Capricorn2481 | 20 hours ago
> 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.
rowanG077 | 20 hours ago
Onavo | 20 hours ago
Capricorn2481 | 20 hours ago
rowanG077 | 15 hours ago
bdelmas | 19 hours ago
No more joy crafting things as a dev…!
rowanG077 | 14 hours ago
doc_ick | 9 hours ago
rowanG077 | 8 hours ago
1. A person building alternatives to photoshop single handedly: https://gizmodo.com/someone-vibe-coded-a-free-knockoff-of-ad...
2. The abundance of game decomps and recomps becoming available. Literally dozens of example in this space.
3. Reverse engineering of obscure software. A ton of oppertunities lie here.
4. As this posts indicate, severely accelerating existing software by re-writing it in language that are not terrible for performance.
5. Analyzing large volumes of unstructured information.
6. Creating one-off engineering and scientific tools.
7. Beating essentially all traditional Linux distribution, see Omarchy.
8. A personal example: I'm remaking the engine of an old game commercial game in rust.
I'm honestly a bit taken aback that this question is even asked. The volume of software is exploding and the power of the individual has increased a hundredfold.
yoyohello13 | 17 hours ago
spankalee | 19 hours ago
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.
criemen | 14 hours ago
pjmlp | 8 hours ago
Note there is already a feedback post from them (currently top one), that they will need to react to this.
yoyohello13 | 5 hours ago
pjmlp | 5 hours ago
The team has posted reaching feature parity with broken workflows past 7.0 release.
https://blog.angular.dev/an-update-on-angulars-typescript-7-...
https://devblogs.microsoft.com/typescript/announcing-typescr...
joe-excom | 19 hours ago
yoyohello13 | 17 hours ago
viraptor | 17 hours ago
CuriouslyC | 10 hours ago
epolanski | 10 hours ago
pjmlp | 13 hours ago
jckahn | 9 hours ago
pjmlp | 8 hours ago
jckahn | 4 hours ago
pjmlp | 3 hours ago
globular-toast | 8 hours ago
Would gold be valuable if anyone could create it at will? Sure, a few people would like the colour and the way it shines, but most would be indifferent. A lot of these things were cool because we knew they were difficult and had technical challenges to overcome. Now it's easy, I just don't care.
yoyohello13 | 5 hours ago
When people post AI projects with genuinely new/interesting ideas, then I am interested.
hannibalhorn | 20 hours ago
shepherdjerred | 20 hours ago
I already pay for subs on both but the tokens are already spoken for with other projects
anonymous908213 | 20 hours ago
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.
epolanski | 10 hours ago
Interestingly, your whole comment implicitly has the answer to this. In the future you don't add code or read it, you only add test cases and have the loops work on covering the new case.
mexicocitinluez | 10 hours ago
Maintainability isn't just for humans. An LLM working in an unmaintainable codebase has the same problems we do. It doesn't necessarily follow that if your code can pass your tests today then it will be able to pass the tests of tomorrow. I'm in healthcare. Regulations and payor rules change constantly. I don't know what tomorrow will bring, but I do know that the code I have an LLM generate tends to focus on the here and now (at the expense of the future). Sometimes that's okay, though. I don't know much about writing a compiler, so it could theoretically work.
This is by no means an anti-AI post (I use the hell out of these tools). But I can still see the cracks in them.
epolanski | 9 hours ago
Rapzid | 8 hours ago
epolanski | 6 hours ago
anonymous908213 | 9 hours ago
epolanski | 9 hours ago
Rapzid | 8 hours ago
Ultimately there isn't enough information on how to most effectively maintain and evolve large, complex software with LLMs yet. We aren't even a year out from Opus 4.5.
Capricorn2481 | 19 hours ago
ncruces | 11 hours ago
spankalee | 19 hours ago
Thaxll | 18 hours ago
wut?
scotty79 | 9 hours ago
mkesper | 14 hours ago
Motivations
epolanski | 10 hours ago
In the same way you trust any build of the official compiler: it passes all of the existing tests.
globular-toast | 9 hours ago
epolanski | 6 hours ago
An LLM has reimplemented a 2 times faster version of a program developed by a team of dozens of brilliant engineers led by few of the biggest experts in compilers and programming languages in the world.
While maintaining 100% test coverage and so far compiling every single project that the original compiler did.
If your takeaway here is "yeah, but the other one has been checked by dozens of paid devs and an entire community", and still those dozens of devs with the backing of thousands of contributors could not make a compiler faster I can't buy say: "maybe we humans aren't as good as writing code as we thought and LLMs are exposing us".
scotty79 | 9 hours ago
Jcampuzano2 | 8 hours ago
Its the equivalent of telling individual people they are the problem when it comes to leaving their living room lights on when not in the room or they don't recycle all their stuff correctly when companies/corporations have orders of magnitude more waste.
wg0 | 14 hours ago
>Spent over $400,000 in API priced tokens with GPT-5.6 Sol and GPT 6 Astra. They wrote over 1.3m lines of Rust over multiple months of /goal loops and never got past like 84% compat.
Then they let Claude code lose on the problem:
> I figured it'd be fun to throw Opus 5.5 at this. It had a working v0 in 10 hours. I assumed it kept using the code the Codex models wrote. I was wrong. Opus 5.5 started from scratch. It got further than Astra in 1/10th the time.
In the warnings from README.md
> Also worth mentioning: I've never read a line of this code.
orthogonal_cube | 13 hours ago
I am so confused about the motivation behind this.
LelouBil | 12 hours ago
JBits | 11 hours ago
Rapzid | 9 hours ago
orthogonal_cube | 9 hours ago
owebmaster | 9 hours ago
chasd00 | 11 hours ago
orthogonal_cube | 9 hours ago
epolanski | 12 hours ago
Seems obvious, experimenting with what it's possible with LLMs.
jckahn | 9 hours ago
nialv7 | 12 hours ago
xedrac | 11 hours ago
globular-toast | 10 hours ago
true_religion | 10 hours ago
globular-toast | 9 hours ago
true_religion | an hour ago
It doesn't mean that all price points are fictional, it just means that in edge cases such as this one, the reasoning breaks down.
dwattttt | 10 hours ago
xnorswap | 10 hours ago
I don't know if it's an accounting trick or genuinely less usage, but since 5.5 I've not had to think about limits at all.
wg0 | 9 hours ago
benrutter | 13 hours ago
Tangent here, but I think this bit is super interesting!
You could viably hire someone to do this work for that kind of money - I think the interesting thing is that substantially less interested/experimenting engineers would consider paying for a human to do this work, than would happily chuck a big amount of money into an LLM.
I don't have any suggestion about why that exists, but it's a strange and interesting contract.
chadcmulligan | 13 hours ago
fiforpg | 10 hours ago
I'm using past tense because iirc NSF has recently reduced their funding volumes, although I'm not following the situation very closely.
binlog | 10 hours ago
flossly | 13 hours ago
I used a lot of OpenAI models to try and complete this port. In total I did over $400,000 in API priced tokens with GPT-5.6 Sol and GPT 6 Astra. They wrote over 1.3m lines of Rust over multiple months of /goal loops and never got past like 84% compat.
When I saw how little my Claude Code limits were burning, I figured it'd be fun to throw Opus 5.5 at this. It had a working v0 in 10 hours.
I assumed it kept using the code the Codex models wrote. I was wrong. Opus 5.5 started from scratch. It got further than Astra in 1/10th the time.
I let it keep going, and it definitely did. Total token spend was ~$24,047 of API spend over 2 weeks. I was using my Claude accounts, and it worked out to somewhere between 925% and 983% of my $200 plan weekly limits.
Expensive, for sure, but not that bad considering how much work has went into typescript-go.
flossly | 13 hours ago
Topfi | 12 hours ago
Ouch, that is brutal and honestly, quite embarrassing but confirms what I have been seeing for a while. Personally, I find output from current OpenAI models still very hard to parse (though it has gotten better vs the pre-trains from both labs in mid/late 2025), thus hard to truly understand, verify and get comfortable maintaining vs current Anthropic models. I do occasionally see a higher ceiling in well scoped tasks with OpenAI models at the cost of (frequently) deviating from the original prompt in (sometimes) very destructive ways.
Could be that this hard-to-read output doesn't just go over my limited capacity/skills but with current models can become simply impossible to untangle beyond a certain size even when one has (essentially) infinite resources via multiple subs and different models.
Would also work with my suspicions for why OpenClaw (mainly build with Opus 4.5 and its post-trains) has been this hard to truly "fix", requiring highly paid Nvidia engineers, multiple months, (literally) infinite resources from OpenAI including access to internal models and yet still holds records for CVEs. Heck, another one was found just 7 days ago after what I'd argue was one of the most extensive hardening sessions any piece of software has ever undergone.
Makes my (multiple) decisions to start from scratch more than once on a major reworking of the existing tabbing interface in Firefox a bit less painful. Learned with each, found gaps in my knowledge, thanked the amazing docs the Firefox devs have been maintaining for decades and while starting from 0 was painful, getting back to MVP is easier than ever. When I hit a point were I was starting to struggle to truly parse additions a model was making to the patches applied to Firefox source code (even if they worked), I always found that pushing even slightly beyond that would incur painful, but hard to notice regressions, introduce major DB maintenance burdens as some models struggle to understand that in development regressions and incompatibility are acceptable and schema transitions aren't needed pre-release (still a case with GPT-6.1 Sol, less so post Fable for Anthropic), make me uncomfortable concerning privacy/security/data loss prevention (especially as I have seen Fable 5 cut some privacy/proper data removal corners in simple CRUD) and simply take away my control about the implementation. Wouldn't feel right to release something in that state, what I have now is fully understandable and thus could be maintained even without models.
Still expecting bugs of course, massively dreading security findings or even worse, possible data loss given browsers handle some of our most important personal+professional data and will surely have taken some embarrassing approaches that might have a much more performant solutions when implementing an infinite canvas of webpages, but still, rather that then also knowing I wouldn't even know where to start understanding a feature.
More so if, like with ts-rust, even (nearly) infinite tokens couldn't get me unstuck.
Rapzid | 10 hours ago
Maybe it just needed to be prompted differently? Maybe Astra starting from scratch could have done it? Maybe Opus was somehow trained more on the Golang implementation.
It's curious, but again little insights.
Topfi | 9 hours ago
Prompting wise, would be interesting to know how much steering truly happened across the project, if one wanted the model to truly work without detailed input, there isn't much that could be done to improve. How much was lined out and set I'd love to know, don't see it anywhere in the commits though, just the AGENTS.md and a few other docs files. "Port TS compiler, checker and LSP to Rust, never ask any questions" would be pretty funny though.
scotty79 | 9 hours ago
What's most interesting is that Opus wasn't told to toss out the Codex crap. It decided to do that on its own. Which might mean that LLMs are actually getting a reasonable taste.
I've seen on youtube that some guy implemnted game engine with Astra and Claude. Astra wasn't really given fair chance because it didn't decide to work as long as Claude and the guy didn't force it. But still, scripting code within the engine that came from Astra was chaotic, messy, piling up things, but the code that Claude made looked downright pleasant.
sreekanth850 | 10 hours ago
semiquaver | 10 hours ago
TiredOfLife | 10 hours ago
flossly | 9 hours ago
Well that backfired. Now all geeks reading this know that Opus beats Astra's ass hands down.
____mr____ | 13 hours ago
I don't think I've seen an enterprise paying API prices doing these sorts of rewrites, and honestly, I think until that happens I will remain skeptical about LLM AI's viability as a profitable business.
viraptor | 10 hours ago
true_religion | 10 hours ago
ForHackernews | 10 hours ago
flohofwoe | 8 hours ago
owebmaster | 9 hours ago
pmkary | 8 hours ago
rowanG077 | 7 hours ago
pmkary | 4 hours ago
thrance | 4 hours ago
gavinray | 4 hours ago
It's jumping through hoops to preserve initial Go semantics:
https://github.com/pingdotgg/ts-rust/blob/main/crates/ts_gop...
https://github.com/pingdotgg/ts-rust/tree/main/crates/ts_gop...
skrtskrt | 3 hours ago