106 points | 19h ago | Discuss on Hacker News | Back to Radar
# “The Slop Line"
Everything below this was written by my LLMs, not me.
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.
However, it has a relatively large runtime, so TinyGo is often preferred when bundle size needs to be small.
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.
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
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.
Notorious examples, the recent Github Copilot runtime, and the Microsoft 365 microservices.
The "shape" of the code would be different?
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).
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).
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.
If you wanted to point to their evidence you couldn't because they don't have any.
I would not want a core internet router or a kernel to be implemented in JS. But I am happy it is used elsewhere.
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.
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.
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.
Writing Rust, Zig, or Go, you would still control memory manually, where it matters.
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 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...
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.
Maybe. Who knows, it's all changing so fast!
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...
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.
More unserious and unmaintained projects at 400k a pop. Sick.
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.
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.
3 GLs are going to slowly fade out as LLM tooling improves, and coding looks increasingly as envisioned by 4 GLs advocates.
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"
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).
Coding as we knew it will be left to weekends and retro-computing handcraft fairs.
The clear reason this has worth is that it's much faster than TSC.
> 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.
No more joy crafting things as a dev…!
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.
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.
Note there is already a feedback post from them (currently top one), that they will need to react to this.
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...
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.
When people post AI projects with genuinely new/interesting ideas, then I am interested.
I already pay for subs on both but the tokens are already spoken for with other projects
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.
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.
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.
wut?
Motivations
Test model capabilities
Make a fast TypeScript type checker
Make a ts checker that can work in WASM with high performance
MemesIn the same way you trust any build of the official compiler: it passes all of the existing 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".
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.
I am so confused about the motivation behind this.
Seems obvious, experimenting with what it's possible with LLMs.
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.
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.
I'm using past tense because iirc NSF has recently reduced their funding volumes, although I'm not following the situation very closely.
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.
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.
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.
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.
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.
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.
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...
Comments are loaded live from Hacker News and are not stored by Mid or Real.
ingen0s 19h ago on HN
colomo 19h ago on HN
spense 19h ago on HN
i'd bet this is a few subscriptions over a few months rather than paying directly for tokens.
TiredOfLife 8h ago on HN
hedgehog 19h ago on HN
JacobAsmuth 19h ago on HN
LeFantome 17h ago on HN
scotty79 3h ago on HN
JacobAsmuth 58m ago on HN
sghiassy 19h ago on HN
I wonder how much AI companies lost on this?
Edit: not that I’m worried about them, I’m just curious
esperent 18h ago on HN
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 18h ago on HN
janalsncm 18h ago on HN
rich_sasha 14h ago on HN
I think a clearer picture would be from inference-only orgs.
MBCook 18h ago on HN
sghiassy 18h ago on HN
MBCook 18h ago on HN
scotty79 7h ago on HN
sghiassy 6h ago on HN
Then take the minutes you used and compare what it would’ve cost, if you paid by the minute
Rapzid 18h ago on HN
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 18h ago on HN
Rapzid 17h ago on HN
It's also TheoGG sooooo.. Those influencer instincts tho.
aizk 18h ago on HN
woozlewuzzle 17h ago on HN
pebal 14h ago on HN