> That doesn't hold anymore? AI doesn't care how hard or easy a migration is if a test suite exists.

Sure, but that only matters if migration is going to be the last thing anyone does on a project. Unless you think typescript 7.1 ought to be enough for anybody, it also matters what the typescript team wants to write/read/reason in.

I just vibecofed tsasm. tsrs is obsolete now and anyone who still uses it is hopelessly behind the times. The tsrs team should delete the repository immediately and join my project.

Your answer is within the comment you wrote. AI is maintaining tsrs whereas humans are maintaining tsgo.

Your question boils down to "why would humans maintain something?" which could have a variety of answers depending on context.

I never understand why people say things like this. It is not uncommon for languages to have multiple implementations, everything must not be abandoned for Rust man.

Because TSGO is stable and compatible?

I assume that most of the speedup in ts-rs does not simply stem from using a language without garbage collection, but actually from doing smart optimizations that can be done in any langauge.

Similar to how uv in the Python world explained that their implementation being in Rust has very little to do with the most impactful speedups they did.

The reason Anders gave at the time was Rust effectively outlaws cyclic data structures, which was not fitting of their implementation.

TSGO is already plenty fast and overkill for most projects.

Sure the Rust version is faster but the difference is probably only noticeable in the top 1% largest projects.

Please you port it if its so easy, the tests are available on gh. I wont be using an llm ported ts compiler anyways, and neither would many others

Its a great way to divide and kill the popularity of your project. I made sure bun is no longer used in my devices or projects that depend on it for example, I'm not alone in this.

As someone maintaining a close to 3M life Rust codebase, the downsides are real, especially rustc speed. I contribute to the mbx cache project but it only helps so much. It's only a small exaggeration to say that I fantasize daily about pursuing to Go.

Another advantage of AI, though, is that it becomes easier to maintain more than one TypeScript compiler. Perhaps there's some benefits to having some diversity?

If an AI agent could vibe-optimise tsgo, why port it all again over to rust?

Im not because nobody actually ever learns anything. For every one person that learns something the other 99% of the population gets lazier and dumber, ponder how that might play itself out.

This is probably the most harmful tech ever created simply because how many people trick themselves into thinking they're smarter while actually becoming much dumber. We're actually cooked.

If I recall correctly, a few of both - there were instances where some work could be done more lazily/minimally (https://github.com/microsoft/TypeScript/pull/64476), and there were instances where we changed our allocation patterns and played around with some struct layouts. We originally strived not to drastically reorganize our data structures to make things easier to port, and we have more flexibility now. We're continuing to experiment more here.

I never see this caveat mentioned in all the "... vibe-ported to Rust" threads, which makes me wonder who comments on these projects. I hand-ported a few TS hobby projects to Rust+WASM pre-AI and realized there are only two ways to go: Do a low effort translation and create very unidiomatic Rust code or redesign the application from the ground up. There's no middle ground. Option 1 is almost a waste of time and option 2 is incredibly difficult.

> Never deallocating would have been sound (missile memory management: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98... ).

Calling this a breakthrough in memory management is an understatement. Call up the Turing Award committee. We just discovered a solution to the halting problem! Turns out that for certain applications the answer is unequivocally "yes"

With sanitizers (https://github.com/oxc-project/tsrs/blob/main/notes/mem-recy...). We're back to C I guess. I hate this project now.

> load-bearing seam

Zing!

Compilers often just build up more and more data structures in memory until the end when they then release everything more or less at once. With an arena you can then just throw away the whole arena at the end, assuming there are no resource handles that need to be closed in drop().

A long time ago I read an article about someone speeding up a C++ compiler that is itself written in C++ (was it g++? maybe clang?). They simply patched out delete so it did nothing. The compiler used marginally more memory but ran much faster, since releasing all the small objects one by one is just useless work at the end of the compilation.

A GCed language has a similar behavior and could therefore be fast in that case. It just builds up all the objects and then when the program exists it doesn't have to GC them all, it just throws away the whole process memory. So I can imagine one could "optimize" a compiler written in a GCed language by deactivating the GC.

Oxlint already has type-aware linting, integrated with TS7/typescript-go.

> Then why are the performance graphs the headliner topic in the article?

If you’ve got it, flaunt it?

> The WASM sandbox is barely a footnote.

This one is a real head scratcher. The sandbox was clearly what set them on this path.

Maybe they believe the performance gains are worthy of being discussed by themselves?

What objective things can you mention about the WASM sandbox besides saying "it works"? People prefer seeing good benchmarks.

While this is true - and I see the same sentiment as i am about to make ad nauseam - it is kind of amazing how far the goal posts have moved in such a short space of time.

That's fair, I was thinking the same – porting must be simpler, especially if there's already a substantial test suite

Totally fair. The thing is, though, agents often write code in ways I don't expect, and I don't think any human would write, which makes me think that code may also break in a way that no human expects or would have written a test for.

The only group of people saying this are those who didn't have much technical ability to begin with.

Found the meat proxy. Your kind will be the first to be replaced. Useless without the machine doing the actual work of thinking.

You’re a waste of time.

Just to put everything in perspective, I recognize fully that Cloudflare had a use case for tsrs with WASM sandboxing. I am addressing your larger point about this sort of thing becoming the norm.

> We cannot ignore individual benefits in contributing, but that is not everything.

Individual benefits are the very foundation of most collaborative efforts. Pharmaceutical companies get payouts via patents for researching life-saving medicine. Even with money taken out of the equation, many academics slave for years over their research in hope of recognition either via Tenure or Nobel Prize. Ignoring the fact that people want credit for their work is dangerous and irresponsible.

Forking projects that are near-complete or have already undergone major refactors just to snipe them last-minute with vibe coded efforts is going to kill collaboration. I'm never building another project in the open again because that is precisely what I'm aiming to avoid.

It sounds like the big 7.1 performance trick will be unmanaged arenas, so yeah maybe something your LLM agent picks up for "cheap".

Why would they bother merging his vibe slop if theirs is better?

Nice. I missed that. This is good news.

That was pre-AI. Ironically if they waited just another year they could've done this port directly to Rust themselves.

That's interesting. A go version to iterate on the code and a rust version to run the code might be an optimal split here.

For VSCode: 4x speedup vs TS 7, 3x vs TS 7.1

Yes, it's in the article.

They say the point in the article - WASM

The success of "modern" CLI tools written in Rust (uv, oxlint, turbopack) show there's a clear demand for faster tools in general.

Also, faster feedback loop is crucial for AIs, so I guess this makes sense.

Faster feedback loops almost always deliver improvements elsewhere.

> Is the TS compiler unbearably slow?

It's not. Even the JS compiler is still fast enough for many projects given the single core improvements in hardware (eg Apple Silicon).

[flagged]

[dead]

What does that prove?

I can vibe code my own CMS with one major version update everyday but that means nothing.

You should say you're staying fungal infection free as it's named after the Rust fungus not the chemical reaction even if that's what people think these days.

Did you know? Even stainless steel RUSTs in sea wind.

So excited that you avoid writing a single line of it at all costs.

I assume you mean jsdoc + tsc in js type checking mode (tsc --allowJs --checkJs --strict)?

inty infers more - including generics (parametric polymorphism), while tsc is more of a simpler local inference.

inty is more strict - it accepts less programs than tsc would. This is mostly on purpose (to our benefit) as some of those programs have unsound code like array covariant (downcasting array members of the wrong type). tsc makes it easier to slip through these bugs.

And if tsc + jsdoc is good then the same question remains (do we really need the TypeScript language?)