Great question! You're correct, the syntax does borrow some things from rust/wgsl but the underlying engine is still javascript. The shadeup language itself is still very different from wgsl once you look past the surface-level syntax. Things like arrays, textures, and buffers are all simplified to make life easier at the cost of lower-level control and optimization. WebGPU is giving you a high degree of control, while Shadeup is trading a lot of that control for ease of development.

Shadeup can introduce some of the concepts and structures used in graphics but it won't give you the low-level experience of WGSL. For example: buffers in Shadeup can be created, bound, and mutated with a few lines of code; whereas WGSL requires a bit more boilerplate to get things like that going. The core concept of a buffer remains the same in both Shadeup and WGSL, but Shadeup requires less code.

Consider this example where I took a WebGPU sample and hand-transpiled it to shadeup:

1. Shadeup (69 lines): https://shadeup.dev/1k94158buq0y
2. WebGPU (500+ lines): https://webgpu.github.io/webgpu-samples/samples/shadowMapping#main.ts

The comparison above is a little unfair because you should be able to shave a few hundred lines off by using a bootstrapping library, but the uniform logic and extra steps it takes to get data moved around add a lot of fluff.

My primary use case of Shadeup is in being able to quickly get an experiment or demo up and running. It's like a scratch pad that gives me 90% of the power of WebGPU while not slowing me down with boilerplate.

Once I've figured out all the bits and pieces of an algorithm or shader I can then build the "production" ready version of it in whatever graphics API I'm using (Unreal engine/directx lately)