During Metal Shading Language's development, there were multiple opportunities to engage for Apple to open up their shading language toolchain, and make MSL a standard that would be respected by multiple people. They ignored that advice, and now lots of people grumble about writing MSL. It is, in many people's eyes, a quite decent shading language, but it's "different enough" and for a niche enough platform (in the games world) that it pays the price heavily. Tooling is pretty abysmal, and GPU debugging in Xcode is not the greatest experience.

Now, with that said, Apple did not propose MSL to the WebGPU working group either. Apple originally proposed a hilariously underspecified fork of HLSL called WHLSL which had three goals: 1. Be a safe shading language for the web, 2. Be compatible with existing HLSL content, 3. Add pointers.

Nobody ever justified the existence of that last one to me or the rest of the group, other than making the Metal implementation slightly easier for Safari, since Metal's binding model is based on pointers, and coincidentally, the Safari pre-release only supported binding pointers, and not the standard HLSL way of doing things. But still, the WHLSL proposal was interesting to a lot of people because HLSL seemed like a good language to start from.

After a lot of debate, Apple secretly went back to the drawing board, and released a revised version of the language, WSL, which dropped the goal of HLSL compatibility but still has pointers for some reason. Nobody has ever explained why it has pointers, despite everyone continuing to ask. The goals are still there if you want to read them [0].

https://github.com/gpuweb/wsl#goals

Thanks for the summary. It highlights how "collaboration" from Apple's perspective works. Throwing something over the fence, and then going back to discuss things in secret.

Thanks for providing an overview.

> a modern shading language not stuck being a C dialect

SPIR-V allows you to compile from whatever you want, and avoids the hideously complex beast that is C++ needing to be part of the browser's API.

The track record of industry GPU language development is very poor (arguably even disastrous).

I worry that we now just count on nice languages / compilers magically appearing deus ex machina, and we end up not having any. Big multiplatform frameworks like Unity will just put a SPIR-V backend on their existing tooling.

The rest of us will be stuck with POC-quality GLSL transpiler tools, without the browser devtools and other tooling support that we slowly got over the ~10 years of WebGL history.

(I'm not saying GLSL is that excellent, just that could be heading backwards from current almost-good-enough GLSL implementation quality in WebGL.)

You already see this with Vulkan, where many studios opt for middleware engines instead of having to deal with all boilerplate themselves.

You see this on Android and Switch, where most Vulkan related stuff, is based on Unreal and Unity tutorials.

Metal Shading Language is a C++ dialect. HLSL is as much of a C dialect as GLSL is. And I would argue that C++ provides no benefits over C for shading languages.

I prefer GLSL to Metal Shading Language.

Thankfully all proprietary shading languages have moved on from GLSL.

Indeed, I really appreciate MSL being a C++ dialect.

Moved but remained proprietary. So the problem is not solved. Language shouldn't be proprietary to begin with. It's an obsolete and invalid practice from the last century.

For languages? That's a dead end really. That's why whatever Apple will produce will also be dead, as long it's proprietary. Apple is stuck in that mentality and has hard time getting out of it.