4 ms·

This is super interesting, and something I’ve been thinking about from a different (non-game) angle: build tools. It’s cool that ESBuild/SWC (and coming soon Bu

This is super interesting, and something I’ve been thinking about from a different (non-game) angle: build tools. It’s cool that ESBuild/SWC (and coming soon Bun[1]) exist as fast native compilers. But most of the rest of the JS tooling world is written in JS, and often performs expensive (and frequently redundant) parsing to AST. This code is often very static, its biggest performance hit is usually cold start before the JIT. And it’s increasingly common that the code is written in TypeScript, which has tons of static analysis potential. It would make a ton of sense to have a generalized AOT compiler for these tools. And it would be good for the ecosystem, allowing higher build performance overall while preserving portability between underlying bundlers. I know there’s a get in touch section (which I’ll avail myself of), but if the author’s reading I’d be curious if this is a use case you’re considering. 1: https://bun.sh/ https://bun.sh/

munificent 5y ago
> And it’s increasingly common that the code is written in TypeScript, which has tons of static analysis potential. It's probably worth noting that TypeScript's type system is deliberately unsound in a couple of corners that make it hard for a compiler to rely on the type system for optimization purposes.
- eyelidlessness 5y ago
  I’m very aware of that, both from building libraries around the type system and watching the type system itself evolve over the last few years. While unsoundness is still a principle of the project, quite a lot of it has been addressed since 3.6 or so. But an optimizing AOT compiler doesn’t need TS to be sound any more than a JS JIT does. It just needs to optimize the paths it has confidence in. To the extent TS code hasn’t escaped type safety, a compiler can be aggressively strict and optimize wherever the types are unambiguous. And it can fall back to the dynamic compilation it already has otherwise.

munificent 5y ago

> And it’s increasingly common that the code is written in TypeScript, which has tons of static analysis potential. It's probably worth noting that TypeScript's type system is deliberately unsound in a couple of corners that make it hard for a compiler to rely on the type system for optimization purposes.

eyelidlessness 5y ago
I’m very aware of that, both from building libraries around the type system and watching the type system itself evolve over the last few years. While unsoundness is still a principle of the project, quite a lot of it has been addressed since 3.6 or so. But an optimizing AOT compiler doesn’t need TS to be sound any more than a JS JIT does. It just needs to optimize the paths it has confidence in. To the extent TS code hasn’t escaped type safety, a compiler can be aggressively strict and optimize wherever the types are unambiguous. And it can fall back to the dynamic compilation it already has otherwise.