| |
| ▲ | AbuAssar 7 hours ago | parent | next [-] | | Go needs a garbage collector while rust doesn’t. | | |
| ▲ | Lvl999Noob 7 hours ago | parent | next [-] | | 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. | | |
| ▲ | zamalek 7 hours ago | parent | next [-] | | Apparently there were some design issues (raised and ignored) that made it unusable for many languages. | | |
| ▲ | kg 3 hours ago | parent [-] | | 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 :) |
| |
| ▲ | 5 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | Tadpole9181 7 hours ago | parent | prev [-] | | 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. | | |
| |
| ▲ | msdz 7 hours ago | parent | prev [-] | | Yes, of course, but couldn’t you have/make one in WASM too? (I have no clue how memory is allocated there) | | |
| ▲ | jerf 7 hours ago | parent [-] | | 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). |
|
| |
| ▲ | ZiiS 7 hours ago | parent | prev | next [-] | | 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). | |
| ▲ | Tadpole9181 7 hours ago | parent | prev [-] | | 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. | | |
| ▲ | tgv 6 hours ago | parent [-] | | For workers, you only need to strip the types. There's no need to do the expensive checking. | | |
| ▲ | Tadpole9181 6 hours ago | parent [-] | | Did you read TFA? > 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. |
|
|
|
