Besides the big studios already abstract the graphic APIs on their in-house engines anyway, or they outsource to porting studios.
Usually the HN community, which is more focused on web development and FOSS, seems to miss the point that the culture in the game industry is more focused on proprietary tooling and how to take advantage of their IP.
The whole discussion around which API to use isn't that relevant when discussing about game development proposals.
It is more akin to the demoscene culture, where cool programming tricks were shown without sharing how it was done, than the sharing culture of FOSS.
If NVidia hadn't made their C++ wrapper available, I very much doubt Khronos would have bothered to create one of their own.
> The whole discussion around which API to use isn't that relevant when discussing about game development proposals.
OK, so if the graphics API doesn't matter, why did your parent comment participate in the graphics API war?
(BTW, I agree with you that the graphics API doesn't matter too much anymore. But I think if you're going to attack Vulkan, you should do so based on specific technical reasons.)
> If NVidia hadn't made their C++ wrapper available, I very much doubt Khronos would have bothered to create one of their own.
Khronos isn't a company—it's a standards body. As NVIDIA is a member of Khronos, "Khronos" did bother to create a C++ API.
I rather use APIs that embrace OO, offer math, font handling, texture and mesh APIs as part of SDKs instead of forcing developers to play Lego with libraries offered on the wild.
> Khronos isn't a company—it's a standards body. As NVIDIA is a member of Khronos, "Khronos" did bother to create a C++ API.
I guess that is one way of selling the story.
But it's not "pure C". C is just the glue. You can use the C++ API if that's what you want, and you have a completely object-oriented API.
Can Linux never have an "OO interface" because all syscalls trap into a kernel written purely in C? Of course not, that would be silly. The same is true here. If you program against an object-oriented C++ interface, then you have a fully object-oriented API.
I find interesting that a Rust designer thinks otherwise.
You can easily call into something with a C ABI (er, OS ABI designed around C, or whatever is the correct technical name) from any language. Try that with C++ :D
C++ provides better tools to write safer code than C ever will.
I would rather be using Ada, Rust, System C#, D, <whatever safe systems programming language>, but until OS vendors start providing something else, C++17 will have to do.
Since 1994 I only write C code when forced to do so.
And the reason why it's C is so that you can bind from multiple languages. DirectX doesn't have this problem because it's not plain C++, it's COM--which is designed to support bindings from multiple languages. But COM is effectively Windows only, and Vulkan needs to be platform independent. So Khronos made the correct choice here.
As you acknowledged, they also created an idiomatic C++ wrapper, so I don't see what your complaint is at all. Khronos did the correct thing every step of the way.