[muglug]

A major rewrite in another language is also unusual for this project.

It took TypeScript a year to go from announcing tsgo to releasing TypeScript 7.0. That work was done in parallel; here the work is being done serially — and it’s likely to take much less than a year for a new release.

[chmod775]

> It took TypeScript a year to go from announcing tsgo to releasing TypeScript 7.0.

These are not comparable at all. The bun "rewrite" really is more of a translation of a software that is mainly dogfooded, created with an at best loose regard for a wider ecosystem.

TypeScript 7.0. by comparison is not just a translation from one language to another. It's a true rewrite that at the same time has to consider a massive existing ecosystem (which needs to catch up first or you risk fragmenting it). Plus you might as well consider 6.x part of the effort, since that was the stepping-stone.

Also where bun really is just a runtime implemented with a bunch of glue code plus supporting tooling, TypeScript is much more complex. Change one part of TypeScript and you can get cascading issues somewhere else in the compiler easily. Change something in Bun and you'll likely just break some discrete part.

[dminik]

It's funny, but a large reason for why Go was chosen was explicitly because it has semantics close to TypeScript and that made it automatable:

https://github.com/microsoft/typescript-go/discussions/411#d...

> But this wasn't a compiler redesign, and the TypeScript to Go move was far more automatable and more one-to-one in its mapping.

So basically the opposite of what you're saying.

[chmod775]

IMHO it's not the same car, even if its engine initially was a 1:1 rebuild using other alloys. But you're right I overstated and made myself look dumb (by a lot really - this is nothing like having 2 independent C compilers for instance).

What's taken 1:1, deliberately, was the compiler core. That was almost perfectly 50% of the non-test code. A close translation of that was a starting point, but open CHANGES.md or it's history and you'll see it's quickly diverging even on its surface.

The closest matching, interesting large area of it is probably the checker. Easily recognizable on a function level, even if not being a single file anymore:

https://github.com/microsoft/typescript-go/tree/main/interna...

https://raw.githubusercontent.com/microsoft/TypeScript/refs/... (The TS file is 3MB and github won't display it inline)

You'll find a lot of the same data structures (as far as that's possible in a TS-to-Go translation + ripples from areas that were more heavily changed) and functions lying around, just in slightly different places. Because of the AST changes and TS/Go differences on a line-level each function might look different, but where there is a loop in the TS one, there's probably one in Go.

The other half of the project is heavily changed or completely new/different (like concurrency, less weird language service).

[skeledrew]

> The bun "rewrite" really is more of a translation of a software that is mainly dogfooded, created with an at best loose regard for a wider ecosystem.

This seems self-contradictory. If it's just a translation, doesn't that mean it remains fully compatible with that wider ecosystem? All the existing APIs retain identical behavior given the preexisting comprehensive test suite that had to go 100% green after all.

[chmod775]

> This seems self-contradictory.

It's not.

Passing an existing test suite just moves the optimistic lower bound to incidental compatibility, it doesn't move it to intentional - "regard" implies you gave it thought.

Plus, it's not just about code: it's also about giving the ecosystem a migration path. Dumping 500k LOC on people and discontinuing development of the zig version effective immediately (there hasn't been a release since and the zig tree is only a reference - the build script is removed afaik) is the opposite of what TypeScript did. If you broke someone's N-API module because of a regression not caught by your suite they're now between a rock and a hard place.

The good news is that there's nobody there to notice. The bun userbase is miniscule* compared to TypeScript's.

* negligible? irrelevant? laughably small? I'm struggling to find an adjective that does the difference justice.

[skeledrew]

That "incidental compatibility" point is a good place to start. Unless there are serious gaps in the test suite, one can have high confidence that there's no regression from the pre-fork version in documented behavior.

What kind of migration path beyond 0 regression do you think is needed? And if the latest Zig version is no longer available, how were at least 2 forks based on it submitted to HN? And what kind of release are you expecting when the team is working to fully migrate to the port (so far it's still marked canary)? If someone's using an untested (ie. very likely unpublished) API, well it sucks to be them but they should know the risks.

And again the self-contradictory argumentation. If the userbase is as miniscule as you imagine then your criticisms are essentially meaningless. No ecosystem worth giving a migration path and nobody's N-API module breaking because of a regression, right?

[chmod775]

> And if the latest Zig version is no longer available, how were at least 2 forks based on it submitted to HN?

Where did I ever claim this? I said they don't even have the Zig build script in their repo anymore - they're clearly not intending to make any more changes to it, even if the code is still lying there next to the Rust code.

> If the userbase is as miniscule as you imagine then your criticisms are essentially meaningless.

They're not criticisms, they're observations. The point is that the challenge is not comparable - because TypeScript's existing ecosystem is part of their challenge.

[skeledrew]

> I said they don't even have the Zig build script in their repo anymore

And what does that matter if the ability for others to build the project isn't affected?

> they're observations

So... what do you want? It's all very pointless to even address.

[TiredOfLife]

TypeScript 7.0 was literally a line by line translation. With essential features necessary for adoption still like a year off.

[virajk_31]

Yes, its because Anthropic took over and wanted to showcase their LLM capabilities by porting such a complex codebas.

[taormina]

Everyone’s point is “they have everything to gain by lying about being more done then they are” and “the claims seem at least a bit full of shit”.