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.
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.
Borrow checker aside, I would like to think that its type system inherently makes it safer than a language like C.
You can write bad unsafe code in any language. Rust has a convenient keyword for that. C++ has types.
That is a confidently incorrect assertion.
They said race conditions and specifically exempted data races. You can absolutely write race conditions in rust, they're a logic bug.
As an example, let's say you have two functions A and B. A only works properly if B has never ran for some reason. Let's say they both accept a reference to a value C, and B changes C's value somehow. Because this is rust, we can't have data races, so we wrap it in an ArcMutex or what have you. That doesn't impact the ordering of A and B at all.
If we spawn threads that execute A and B at the same time, it's up to the scheduler if A functions properly.
You are being downvoted but you are absolutely correct. I have never seen someone assert Rust is a 100% safe. Its touted purely as a _memory_ safe language. To claim otherwise is absurd and very telling of the writer's biases
> I have never seen someone assert Rust is a 100% safe
Please copy and paste from my post where that's being asserted
> Its touted purely as a _memory_ safe language
Which is different from what was said... how?
> To claim otherwise is absurd and very telling of the writer's biases
To pretend that those claims were made is what's actually telling of biases.
> How can Codex write fast-to-compile Rust code, do tell?? Do tell!
Because memory safety isn't just about data races. In fact data races are far from Rust's most innovative or important feature. They are a side-effect, the designers had a nice system and saw it can also prevent data-races, so they said "sure, why not".
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.
You need the experience of building and maintaining a compiler to make a great language spec. The tsrs team specifically said they don't want to be trying to change the spec.
These ports are borrowing large parts of the architecture, algorithms, and data structures from the official implementation.
I don't think a spec would facilitate them at such a low effort level and cost.
Because its impossible to stay motivated working on non trivial project when AI is running the show. Its the last thing Id want to do, its soul sucking and the code is terrible. Remember these guys have poured years of actual work, not slop into tsgo. You sloppers wouldnt understand that.
> Why maintain an official compiler that's not even half as fast as the vibe-coded one?
Because at the end of the day, someone has to actually care and put in effort, even if the thing is machine generated, because it can go off the rails.
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).
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.
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?
I walk to the supermarket. I'm pretty sure an F1 car would be noticeably slower.
On foot I cross the little residential street where I live, walk to the corner, cross the busier road using a Zebra that was installed by thoughtful "pedestrian first" local government, then walk to the next corner where the main entrance to the supermarket is.
In the F1 car lets assume somebody already pre-warmed it and so it's ready to go (F1 cars do not "just work" like your family car because that's not required in the F1 rules) I walk to the car park and get in, I need to accelerate quite hard to get the slippery F1 car up the steep drive, but then brake hard to stop and have somebody else check both ways since an F1 car isn't equipped for this in a side street. Now I pull out, takes no time to reach that street where pedestrian me crossed but I can't use that route in a car, so, go through another residential area, turn onto an old main road, turn again, to a roundabout, go into the underground carpark of the supermarket. Once I've parked I'm about as close to the front door as if I were walking from the Zebra. Huh.
the cost between an F1 car and a "regular" car is high, both financially and functionally.
but tsrs and tsgo are not a similar comparison. they cost the same (you download a binary and run it) and are functionally identical. in that case why would you not use the faster & better one?
the question should be, do you always want your groceries 50% faster ?
My car doesn't require a dedicated team of engineers to start and has a trunk to hold groceries :P
The question isn't really if the speed is bad, it's what tradeoffs you need to make to realize it. The F1 car has a very narrow operating condition and so can make tradeoffs that are completely unreasonable for vehicles that need to do other things.
From what cloudflare is claiming, Tsrs gives me more speed without tradeoffs I care about, so why not have the free speed?
No, but I sure wouldn’t mind if I opened my fridge and the food was already there.
Oh boy that’s about the most off the mark car analogy I’ve ever seen and I’ve seen some
If I could afford one, I absolutely would! I'd add a tow hitch so it had some storage and get it all street legal and add blinkers.
If you are travelling a long distance, say over 1000 miles/km, do you always drive? Or do you take an airplane (or a train)?
Bad comparrison. The less time my computer spends doing things the less battery I use.
An F1 car goes faster but also uses more fuel to do so.
Any one tool being a bit faster doesn't make my batter last noticeably longer, but defaulting to using the efficient tooling gets me results I can see.
Do you usually dig up your garden by hand with a shovel, or do you use a rototiller?
Now we're getting somewhere. This is a great example because obviously speed depends on the context.
Obviously a shovel is quite an improvement for home gardeners but big constructions need a completely different tool.
For +99% of TS projects going from eg 10ms to 1ms is not going to make any difference even though it's a 10x improvement. In part because most monitors refresh at 60hz (16ms per frame) but even with +120hz monitors this is not going to have an impact on any workflow. Even for CI network latency is going to be a much bigger factor than improving TS compilation beyond the performance that TSGO already provides.
I think it might have more meaningful impact on high volume use cases, i.e. where cumulative run time is still significant.
That’s already meaningful for at least a couple of companies I’ve seen investing in these ports. It might be niche for individual dev workflows now, but as those evolve it could become less niche (albeit probably still less uniform).
> I think it might have more meaningful impact on high volume use cases, i.e. where cumulative run time is still significant
For sure but those high volume use cases are extremely rare.
Do you dig your garden with an excavator?
Why are bringing Java into this?
I mean... If I had an excavator it beats using a shovel? This is such a silly "gotcha" analogy because the only reason I wouldn't is cost. And cost is not a reason for tsgo to be slower?
"Would you rather have worse software for literally no benefit?"
We should aim to make software as performant, bug free, feature-complete, and maintainable as is cost effective. It's asinine to argue that software shouldn't be fast, not because of some trade off, but just because someone doesn't need it to be fast for small tasks.
Which, mind you, isn't even the case here. Thousands of businesses use typescript for millions of lines of code. Performance gains can mean tens of thousands of dollars in compute or hardware or time; tons of carbon saved from being emitted.
Yep cost is the reason, allegedly the ts team found go a better language for a port and both using a less ergonomic language and switching target every six months have associated costs
And that's a fine argument to make! But this stupid garden analogy is nonsense.
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
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?
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.