Port TypeGPU to AssemblyScript

[PaperPrototype]

At some point I'd like to port this library to AssemblyScript. I think it could be a really interesting use case especially since AS has operator overloading and is fully statically typed.

[iwoplaza]

That sounds really interesting! I remember looking into AssemblyScript at the beginning stages of working on TypeGPU, and we skipped over it since it deviated from JS/TS too much for our use case.

On the other hand, I definitely gravitate towards the more strict numeric typing and operator overloads. We have plans to eventually introduce operator overloading on top of JS/TS as a general solution that things like TypeGPU and TSL benefit from, and strict numeric typing would naturally follow. I would love to divulge more of our plans and thoughts here if you'd like to contribute on that front 👀.

If there are other reasons for porting to AssemblyScript, I would love to hear them, I wanted to get into AS for a while.

[Manish546-gif]

@iwoplaza This is a really interesting direction. The original proposal isn’t mine, but AssemblyScript’s stricter numeric typing and operator overloading seem like they could fit well for higher-level abstractions on top of Three.js, especially where math-heavy or GPU-style workflows are involved.

A small prototype/POC could be useful to better understand DX, performance implications, and how it compares to bringing operator overloading into JS/TS directly.

Would be cool to see how this evolves 👀

[PaperPrototype]

@iwoplaza - I totally understand why you skipped AssemblyScript haha, it can differ quite a bit in how it approaches types. I'm intrigued by your plans to introduce operator overloading on top of JS/TS directly 👀. I'd definitely be interested in hearing more about those plans if you are open to sharing!

@Manish546-gif - Yeah, I've been thinking about all the ways a POC could be done since I wrote this issue haha. Let me expand on some of the things I came up with.

AssemblyScript does have a "portable" syntax that lets you run tsc on I to generate JavaScript, which could be used to get a very quick SOC working with the current library.

AssemblyScript WGSL Compilation Path
Though beyond just using tsc to compile AssemblyScript to JS I'm curious if WGSL could be a direct compile target of AssemblyScript code? You could at least use the portable version of AssemblyScript so that some code reuse can happen between JS/WGSL. AssemblyScript's asc compiler has places where you can "hook" into the compiler and transform the AST or modify the output to match WGSL semantics. Here is a relevant issue for that AssemblyScript/assemblyscript#2497

Something else I thought might be worth mentioning is that you could even fallback to compiling to WASM if WebGPU isn't available (or just as an optional feature).

[PaperPrototype]

The main thing I am interested in is a more direct AssemblyScript first approach where you write non portable AssemblyScript, so you can fully take advantage of AssemblyScript. You could do code reuse between AS/WGSL even with portable AS but I'm interested in the more direct AS version, but maybe that is out of scope for TypeGPU?

Though if that is something TypeGPU would be interested in, then I think it could reallllly open up the web to some insane shared code reuse across WebGPU/WASM and even GPU/CPU/GPGPU capabilities.

[PaperPrototype]

I also made an issue on Binaryen to see if there is any interest in making WGSL a compile target on their end WebAssembly/binaryen#8266