I believe this is a deliberate misrepresentation of the current state of affairs on Vulkan. Likely for the purposes of spreading disinformation about a specification that legions of smart, dedicated, hardworking engineers came up with after countless hours of debate and consensus.

I mean be real...

there is no way that any programmer who actually used Vulkan would find it as pleasant to work with as you imply in your comment.

Here is the list of Vulkan extensions with device coverage.

https://vulkan.gpuinfo.org/listextensions.php

Clicking a bit around, gives the Vulkan support version per device, which on Android is a mess, unless one only cares about flagship devices.

https://vulkan.gpuinfo.org/listdevices.php?platform=android

Now regarding the tooling, since I am spreading disinformation, can you please provide us with the SDK tooling that matches the offerings from Apple, Sony, Nintendo and Microsoft, regarding their own APIs?

Because what LunarG offers is pretty bare bones, and the OEM SDKs pretty much just provide the basic stuff as well, with C samples.

I guess that someone that rather goes hunting for glm, uses sbt for textures, writes their own font rendering engine, compiles shaders from the command line, only knows about RenderDoc is capable of,... will feel very uncomfortable with the available set of Metal tooling and Frameworks.

And this is one of the best tutorials available for Vulkan beginners, https://vulkan-tutorial.com

Most of the extensions are for what are currently pre-production or fringe features, and the WG showed they're not afraid of pulling important (and even not so important) extensions into minor version releases much faster than OpenGL has put things in core with Vulkan 1.1 (I was glad but honestly surprised that the cross-process resource sharing made the cut).

You're definitely right about significant parts of the toolchain being weaker. In particular sorting out how glslang -> Vulkan works in practice is pretty trial-and-error, and if you want to use HLSL it's even more poorly documented. You have to expect to be going through the Vulkan spec (which I will say is much easier than directly using the OpenGL spec). However the Vulkan validation layers are incredible, and leave the equivalents for Metal, DirectX, and especially OpenGL in the dust.

I think you missed the joke.

It was a joke. Read the comment to the end.

I'm pretty sure the comment you're responding to is just a switcharoo-format joke. Unless the last sentence is missing an "un" before "pleasant".

Yeah I assumed that was the omission but that makes a lot more sense lol

My understanding is that Vulkan is specifically supposed to be as low level as possible in order to facilitate device manufacturers creating new hardware and to give developers fine grained control over things if they want it.

I believe the stated strategy is to let third party middleware handle the higher level abstractions so that different approaches that appeal to different people can coexist. This also theoretically reduces driver complexity and thus (hopefully) bugs.

I have absolutely no idea if this is actually a good idea, or if it's working out in practice. In case anyone wants to poke around the ecosystem: (https://github.com/vinjn/awesome-vulkan).

Okay, but none of that was true in 2014. If Apple had been building an ecosystem of Vulkan tooling instead of an ecosystem of Metal tooling, presumably Vulkan would have the frameworks, the Xcode support, and (maybe) some of the debuggability (since Apple could have their drivers' Vulkan shader pipeline target LLVM IR, and then do LLVM-internal stuff from there to enable debuggability.)

So what made Metal a better technical choice than Vulkan, back when the options were "Metal without Apple's support built yet" and "Vulkan without Apple's support built yet"?

Being almost two years older than Vulkan.