Comment by samuelstros
15 hours ago
At this point, why invest further in TSGO?
No matter how many optimizations can be ported from tsrs to ts-go, Rust will be more efficient and enable the WASM use case.
The premise of porting the compiler from TS to GO was ease of migration due to Go's garbage collector. That doesn't hold anymore? AI doesn't care how hard or easy a migration is if a test suite exists.
> 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 would love this to be typescript 8 and 8.1 story (:
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.
Too late I just shipped tsvhdl so you have a hardware implementation of the actual TS compiler. Why steal valuable CPU cycles from agent workflows, off load all transpilation and type checking to a dedicated TSC chip.
Too late I just shipped tsasic so you can have a custom-made board for every single application you will ever write.
3 replies →
I am okay if agents can write code that is very safe in ASM. I am sure code written in Rust are naturally safe compared to asm or c. Waiting for tsasm to be significantly faster and safer than tsrs.
I'm pretty sure a program written in asm by agents will not only be very unsafe, but also very slow compared to Rust, or even Go or Java.
People massively overestimate Rust's "safety" - it has a very nice approach to managing data races, and. that's it.
It still, like every other language/tool we have that shares state between threads, has race conditions, for example.
9 replies →
Did you? GitHub link? because that would be awesome! which asm target did you pick? I looked at using LLVMs' LVM because I didn't want to have to choose ARM or x86? What are some of the trade-offs you made along the way? Wait, are you making a joke and think you're funny? (Hate to be the bearer of bad news but you're not.)
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.
No, the question is now: "How much human mental momentum, ego, and investment is there in and behind any particular project or its forks?"
I for one would be demotivated. Why maintain an official compiler that's not even half as fast as the vibe-coded one?
"Just" publish the language specs and be done.
4 replies →
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.
There are precisely two languages that make the most sense to implement the TypeScript compiler in: Rust and TypeScript itself.
A Rust implementation will have the fastest compilation speeds, memory safety, can easily be compiled to WASM, or compiled to a native node module.
A TypeScript implementation provides the most convenient way for TypeScript code to use the typescript package as a library. Pure JS, no native code or WASM dependencies. No FFI tax, can be jitted.
Go was always a compromise to make a port easier for humans. Go's GC makes it easier to keep the general code structure from the TS implementation. However that GC is also a liability, you sacrifice speed and embeddability.
Personally I'd prefer they went back to TypeScript for the reference implementation, and used Rust for the performance implementation. Go doesn't bring anything to the table anymore.
> There are precisely two languages that make the most sense to implement the TypeScript compiler in: Rust and TypeScript itself.
Incorrect. I can maybe agree that those are the only perfect languages to implement tsc in them (if there is such thing). But in the real world, "perfect" does not actually mean "it's a good idea". Go made the most sense to port to (especially before agents), more than Rust (although C# could also be a good idea IMO).
2 replies →
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.
Fast is one thing, TSGO is fast enough I think, but my god does it suck up memory
I'm always mind-blown when I read stuff like "speed is overkill". Speechless!
do you go to the supermarket with an F1 car?
20 replies →
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?
because Rust will be faster and can compile to WASM which the TS ecosystem needs
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.