Wasm comes with a garbage collector though, no? So a garbage collected language that offloads all memory management to the runtime would actually be better than one that ignored the platform and does its own stuff.
Wasm GC is not an object-level GC yet. It's still a very low level bit buffer GC. It's closer to the memory page management of an operating system than anything like JS's own GC.
The JVM alone has, what, 4 different modern GCs now? Garbage collectors aren't really universal, so they can pose different issues for different languages.
Ignored is a little unfair to the Wasm committee, the Wasm GC is constrained by what is possible to ship in existing Wasm runtimes and the stuff needed by many languages is way beyond what those existing runtimes have available to them.
I think it made sense for them to compromise, at least on the initial version of Wasm GC, to get it out the door. I say this as someone who wants the features that got left out, like interior references :)
Yes, and when you ship a Go WASM package it is already included. But it has a certain impedence mismatch with WASM since it is rolling its own stuff that WASM can't see, I believe the performance is a bit less good than it could be, and it results in very large WASM packages for small amounts of code.
Since a typescript compiler isn't "a small amount of code", you'd have to see specific numbers on the final WASM assembly size to know how relevant that is. I'd expect well-written Rust code to beat well-written Go code on final assembly size by some amount, which may or may not be relevant to any particular use case (since in a lot of cases one "couple dozen megabytes" is much the same as another when it really gets down to it, it's not like Go is going to be emitting gigabytes to Rust's hundreds of kilobytes or something). However I can't judge what AI-written Rust code versus well-written Go code would come out as. AI is not terribly good at being concise (he said, while writing this post between prompts fighting with an AI to make a PR much more concise than it currently is).
You already can run the Go tsc in WASM using mature tools; but it further amplifies the memory and performance difference between the Rust version (which maps more cleanly onto WASM's design).
1. Porting typescript is made easier by the enormous test suite they can copy for verification.
2. They're doing this for workers, so with a systems-level language, there's a much higher potential for CPU and memory savings (an order of magnitude on this first pass, apparently). Driving their compute costs down is very revenue-efficient at this scale.
> Just a few weeks ago we announced supporting native Rust in Workers with the new Emscripten target for wasm-bindgen. When you run entire software build and deployment systems in tight loops on Workers, the benefits of a small memory footprint pay off quickly.
> Overall, our Rust rewrite and following performance hillclimbing has made Prime Agent significantly faster and more resource efficient. With time to input roughly 14x faster than TypeScript and using over 80% less memory after startup
AMD grew their revenue 50% last quarter from the year prior, for 11.5B in revenue. If this team can help continue that or grow that then yes - the amount of money involved here is insane.
Honestly, I think this 'billion' number is also just the ball park for companies you need to pay if you want to buy them.
OpenRouter was sold for 7.5 Billion.
Lets just accept, that these people don't evaluate a company by value but by magic market "what is a sum someone needs to pay for buying a company and what company is somehow worth it to actually buy for this type of money but more in a sense of adding this to your portfolio"
Microsoft should seriously consider porting typescript to rust at this point
reply