Although I tend to bash WebGL and WebGPU for what they offer versus existing hardware, lagging a decade behind, they have a very important quality for me.
They are the only set of 3D APIs that have been adopted in the mainstream computing, designed for managed languages, instead of year another thing to be consumed by C.
Technically Metal is also used by a managed language, but it was designed for Objective-C/C++ first, with Swift as official binding.
Microsoft gave up on Managed Direct X and XNA, and even with all the safety talks, Direct X team doesn't care to provide official COM bindings to C#.
Thus that leaves us WebGL and WebGPU for managed languages fans, which even if lagging behind, as PlayCanvas and ShaderToy show, there are enough capabilities on the shader languages that have not yet taken off.
D3D (up to D3D11 at least) is also a "managed" API since it uses refcounting to keep resources alive for as long as they are used by the GPU, there really isn't much difference to garbage collection.
Metal allows to disable refcounted lifetime management when recording commands since it actually adds significant overhead and D3D12 and Vulkan removed it entirely.
Unfortunately WebGPU potentially produces even more garbage than WebGL2, and we'll have yet to see how this turns out. Some drawcall heavy code actually runs faster on WebGL2 than WebGPU which really doesn't look great for a modern 3D API (not mainly because of GC but every little bit of overhead counts).
The point is that those APIs were not designed with anything beyond C and C++ as consumers, and everyone else has to do their due deligence and build language bindings from scratch.
So we end up in an internal cycle that we cannot get rid of.
Metal and Web 3D APIs add other consumer languages in mind, you also see this in how ANARI is being designed.
Yes every little bit of performance counts, but it cannot be that APIs get designed as if everyone is still coding in Assembly, and then it is up to whoever cares to actually build proper high level abstractions on top, that is how we end up with Vulkan.
> but it cannot be that APIs get designed as if everyone is still coding in Assembly
Why not though? In the end an API call is an API call, and everything is compiled down to machine code no matter what the source language is.
FWIW, the high-level "OOP-isms" of the Metal API is also its biggest downside. Even simple create-option "structs" like MTLRenderPassDescriptor are fully lifetime-managed Objective-C objects where every field access is a method call - that's simply unnecessary overkill.
And ironically, the most binding-friendly API for high-level languages might still be OpenGL, since this doesn't have any structs or 'objects with methods', but only plain old function calls with primitive-type parameters and the only usage of pointers is for pointing to unstructured 'bulk data' like vertex-buffer- or texture-content, this maps very well even to entirely un-C-like languages - and the changes that WebGL did to the GL API (for instance adding 'proper' JS objects for textures and buffers) are arguably a step back compared to native GL where those resource objects are just opaque handles.
Because not everyone doing 3D graphics is implementing AAA rendering engines on RTX cards.
The ANARI effort was born exactly because the visualisation industry refusal to adopt Vulkan as is.
Looking at the ANARI spec and SDK it looks pretty much like a typical C API to me, implementing an old-school scene-graph system. What am I missing - e.g. what makes it specifically well suited for non-C languages? :)
If anything it looks more like an admission by Khronos that Vulkan wasn't such a great idea (but a 3D API that's based on scene graphs isn't either, so I'm not sure what's so great about ANARI tbh).
Python is part of ANARI value proposal, and the standard takes this into account.
https://github.com/KhronosGroup/ANARI-SDK/tree/next_release/...