There is no reason why any given app developer would want to talk to Vulkan directly. It's basically only suitable for a subset of engine developers and low level API programmers.
I also heard some people who were under NDA might have some disappointing things to report about the Vulkan decision process now that it's out. But the question is whether it matters at all whether it's a good API or not, given my impression that it's apparently not intended for interfacing to humans but to higher layer APIs.
This is the primary UX for Vulkan. The problem is not the API PDF for OpenGL you download from Khronos - its all the drivers that implement it. Not only do you have to support he lowest common denominator GL version and then extension-check every higher level feature you want to use with two code paths every time, you also need to work around all the driver bugs you will find across the board with every combination of platform + GPU.
If OpenGL as of 4.5 were implemented perfectly on all hardware on all systems, we would never need Vulkan because everyone could just AZDO for optimization. Since we don't live in that fantasy world where pigs fly and Nvidia releases freedom respecting drivers, Vulkan takes responsibility away from hardware vendors who demonstrably cannot handle the work and puts the burden on the developer, who... probably also cannot handle the work, but thats a per-application problem rather than a fundamental API problem.
You can. Go ahead and do it. Mesa is likely to implement future OpenGL extensions by translating them to Vulkan rather than implementing them natively to the metal, and someone is probably going to make a libgl that targets Vulkan rather than any of the intermediary layers used around the ecosystem.
I'm really excited to play with it as a hobby developer. Simply because I like doing low-level programming/optimizing for the fun of it.
And I'm currently working on my Msc. in computational science (and possibly a PhD. afterwards) so I'm also going to see how easy it is to shoehorn generic-HPC into this API. OpenCL is nice (well... maybe not nice but workable) but historically the graphics APIs have had better performance for less work. But I guess you could count me as a low level API programmer come to think of it.
I believe that newer versions of OpenCL will benefit from Vulkan due to the mutual dependence on SpirV. My biggest hope is that this will finally reduce our reliance on out of date and buggy drivers to get OpenCL support on multiple platforms.
SPIR-V will be a huge boon for everyone and everything I hope, especially given the LLVM support (Haskell or Rust compilers anyone?). But it only augments the compiler step (AFAIK). I've had plenty of bugs in the host-side code before.
And of course, a newer version does not neccesarilly mean that the out-of-date implementations will suddenly become "in-date": if anything they're even more out of date now ;)
https://twitter.com/renderpipeline/status/699346348651507713
There is no reason why any given app developer would want to talk to Vulkan directly. It's basically only suitable for a subset of engine developers and low level API programmers.
I also heard some people who were under NDA might have some disappointing things to report about the Vulkan decision process now that it's out. But the question is whether it matters at all whether it's a good API or not, given my impression that it's apparently not intended for interfacing to humans but to higher layer APIs.