SL looks like an absolute dog's breakfast. I'll be sticking with Go and Ebitengine's Kage shader language.

Using Rust for writing shaders may sound appealing, but that puts a language that is slow to compile into a domain where fast iteration times are crucial. Most shaders can be compiled in milliseconds and e.g. graphical authoring tools rely on this.

This is a fair point and also called out in the discussion section. To some degree, this could be mitigated by hotloading shader code (and compiling shaders in debug mode). However, this remains as a fundamental downside of the approach.

Personally, I think that this is a price worth paying!

"I will pound this square peg into this round hole no matter what...I'm really fond of square pegs."

Conversely, I despise round pegs. On the other end of the hole is a machine that shreds your peg into sawdust, mixes in a liter of epoxy, and reconstitutes it into a Klein bottle, so I'm not sure why I should care about the shape of the hole.

Is that the rustacian perspective? Force a Klein bottle when what I actually needed was a peg in a hole, a peg which has now been destroyed and useless for my purposes? Or will we be torturing another aphorism to death to get to the point.

I don't use Rust. But the point I'm making is that, whether it's GLSL, HLSL, or whatnot, it all has more of a guiding influence over the code that gets compiled and actually runs on your GPU.

There's another project that's similar that's being used by an actual game company: https://github.com/EmbarkStudios/rust-gpu

They see specific advantages here that would outweigh that negative. It's not my space (I play games, but know next to nothing about graphics programming), but there's at least one argument in the other direction.

Why build upon OpenGL ES rather than wgpu?

Not involved, but this page says:

> Currently, in order to narrow down the initial scope of the project, posh targets subsets of OpenGL ES 3.0 and GLSL ES 3.0. However, we are considering to transition to wgpu in the long run.