Very interesting. With rust's ocaml heritage, I'd imagine a straight port from typescript would be simpler and more idiomatic than a port to go. I guess not.

I don't know. Many people implementing DSLs were happy to live with whatever lexx and yacc spat out for years.

It's extremely useful if your distribution platform is the web. However, I find it much more valuable as a type checker than a compiler. I use TypeScript extensively (in several projects) for defining schemas types.

For example, in the Breaka Club (https://breaka.club/) editor, which is not presently exposed to kids yet, we define behaviors for characters, props, mosaics (terrain tiles) and items in JSON. But the JSON has type checking and real-time completion as you type. Not naive property auto-suggestion, we have effect types and they're context aware in that you can refer to targets introduced higher in parent constructs of the JSON — and they're fully type checked. If you refer to a target that does not exist in a context, it won't validate and you cannot save the schema.

We use tsgo for development, but the editor (runtime schema validation) is presently stuck on TypeScript 6 because there's no WASM support.

Now, is it nutty that we're using TypeScript for JSON validation? A little. But it's extremely powerful. We're going far beyond what's capable with Zod or ArkType.

Because you need to keep the compiler running here,

- https://www.typescriptlang.org

- https://code.visualstudio.com/docs/remote/vscode-web

But it's not the only niche, see Typst compiler in wasm for live document generation in the browser.

Theo is making a new twist on the idea of IDE which hosts the application itself. I'm sure there's going to be a video about it soon. But the idea is to embed the whole compilation and type-check in wasm in the browser which then runs the app immediately, as the agents edit the code.

Wasm is a first-class target for Rust, which produces faster and smaller Wasm binaries. My understanding is that you need to use TinyGo to reasonably target Wasm with Go.

Go having a garbage collector isn't necessarily bad, since Wasm has GC, but I think Go's GC can't easily use Wasm GC because Go has interior pointers.

I think the main advantage is size. Rust doesn't need to include the runtime.

I'm assuming they mean because it doesn't need a garbage collector or much of a runtime at all. You can target direct to WASM and use I guess WASI, while Go brings with it a garbage collector and so on.

It does here, https://www.typescriptlang.org

It does have an impact. Discord blogged about unavoidable GC delays in go that occurred because go needed to traverse live memory, their only option (in go) for reducing that pause was to reduce the size of their data set.

https://discord.com/blog/why-discord-is-switching-from-go-to...

GC absolutely has performance costs, even with minimal allocations, because tracing collectors must scan live objects. This is exactly what this post says. Don't know if its really improved over time in real world cases.

Than Go's GC? I think that is fairly unlikely in most cases.

You seem sure like them that JS is not good. They didn't even bother to consider it as a choice!

If you wanted to point to their evidence you couldn't because they don't have any.