Hacker News Reader

Comment by pjmlp | Hacker News Reader

Better tooling.

Also they accepted the world has moved on and CUDA accepted C, C++ and Fortran since day 1.

Shortly thereafter they made the PTX Assembly format available and any language could easily target it for GPU execution.

OpenCL got stuck in a world of C with the same runtime compilation model as GLSL.

Only after loosing to CUDA they cave in and created SPIR and the SysCL C++ implementation.

And they have done it again with Vulkan.

While Metal and DX are object based, even the shader languages are C++ like, Vulkan is all about C.

Recently they decided to adopt NVidia's C++ wrapper.

View on HN

I don't know anyone who thinks Metal is better than Vulkan. In fact I've heard only the opposite.

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.

Any opinions you'd like to share about using Metal? I can't seem to find much online about developer's experience with Metal, which seems bad...

With the rise of middleware engines on the industry the actual APIs are even less relevant nowadays than a few years ago.

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.

> With the rise of middleware engines on the industry the actual APIs are even less relevant nowadays than a few years ago.

> 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.

Well, for me being based on pure C instead of the OO interfaces of other APIs it isn't something that makes me wish to use it.

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.

> Well, for me being based on pure C instead of the OO interfaces of other APIs it isn't something that makes me wish to use it.

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.

Anything that increases our dependency on C is bad.

I find interesting that a Rust designer thinks otherwise.

Anything that increases our dependency on C++ is much, much worse.

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

No problem on Windows thanks to .NET and COM.

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.

Reply on news.ycombinator.com