WHLSL: Web High Level Shading Language
&gt; The language is insprired by HLSL, the dominant shading language for graphics app developers.<p>sorry wat ? <a href="https:&#x2F;&#x2F;trends.google.com&#x2F;trends&#x2F;explore?q=glsl,hlsl" rel="nofollow">https:&#x2F;&#x2F;trends.google.com&#x2F;trends&#x2F;explore?q=glsl,hlsl</a><p>GLSL is used for multimedia apps, user interfaces (Qt at least uses it quite a bit), 3D authoring apps. ISF (Interactive Shader Format <a href="https:&#x2F;&#x2F;www.interactiveshaderformat.com&#x2F;spec" rel="nofollow">https:&#x2F;&#x2F;www.interactiveshaderformat.com&#x2F;spec</a>), fairly used in all the software chain around audio-visual installations, is based on GLSL. It&#x27;s used on android, on embedded devices, etc etc...<p>&gt; GLSL is the language used by WebGL, and was adopted by WebGL for the web platform. However, reaching cross-browser interoperability was extremely difficult due to incompatibilities in GLSL compilers. There remains a long tail of security and portability bugs with GLSL still being investigated<p>and how will implementing a whole new set of compilers for WHLSL solve this ?<p>&gt; And since Windows and macOS&#x2F;iOS don’t support Vulkan,<p>now this is just FUD. you can entirely write vulkan code and have it run on windows and apple platforms.<p>&gt; the incoming SPIR-V would still need to be translated&#x2F;compiled into another language<p>yes, that&#x27;s the freakin point of SPIR-V<p>Also...<p>&gt;  In Metal Shading Language, you could, for example, write a shader that casts a pointer to an integer, adds 17, casts it back to a pointer, and dereferences it. This is a security problem because it means the shader could access any resource that happens to be in the address space of the application, which is contrary to the Web’s security model. Theoretically, it could be possible to specify a dialect of Metal Shading Language that doesn’t have raw pointers, but pointers are so fundamental to the C and C++ languages that the result would be completely unfamiliar. C++ also heavily relies on undefined behavior, so any effort to fully specify each of C++’s numerous features would be unlikely to be successful.<p>followed by<p>&gt; The first is the safe pointer. Some form of reference semantics, which is the behavior pointers allow for, are used in almost every CPU-side programming language. Including pointers in WHLSL will make it easier for developers to migrate existing CPU-side code to the GPU<p>so instead of reusing an existing thing and just add one tiny dot of safety semantics on top of it, well no let&#x27;s just NIH and reimplement a <i>whole new language</i>. 
Seriously, they don&#x27;t want to use a &quot;safe metal&quot; because &quot;pointers are so fundamental to the C and C++ languages that the result would be completely unfamiliar&quot;.<p>So instead, they write a freakin new language - why the hell do they use the familiarity argument then ?