It's still early days for Vcc, I outline the caveats in the landing page. While I'm confident the control-flow bits and whatnot will work robustly, there's a big open question when it comes to the fate of standard libraries, the likes of libstdc++ were not designed for this use-case.
We'll be working hard on it all the way to Vulkanized, if you have some applications you can get up and running by then, feel free to get in touch.
I think the driver ecosystem for Vulkan is rather high-quality but that's more my (biased!) opinion that something I have hard data on. The Mesa/NIR-based drivers in particular are very nice to work with!
The point of Vcc/Shady is to address some of these, in particular recursion is now possible in Vulkan, and control-flow is no longer limited. A lot of those are just historical language limitations and can be eliminated with enough effort.
The elephant in the room is SIMT and the subgroup/workgroup considerations, which don't really require any changes to syntax but indeed needs the programmer to have a good mental model. But I don't think it would be incompatible with raising the bar on expressiveness or host/device code interoperability !
As others have commented, Shady is an IR that happens to have a Clang front-end bolted on, that combination is what I call Vcc. I really don't expect people to start writing shaders in the IR directly, even though has a textual form!
It's very comparable to Rust-GPU, I actually know a really nice person who does key work on that (you know who you are!) and they're actually facing very similar challenges, and we get to exchange ideas regularly. I am confident it's in good hands.
We'll be working hard on it all the way to Vulkanized, if you have some applications you can get up and running by then, feel free to get in touch.
I think the driver ecosystem for Vulkan is rather high-quality but that's more my (biased!) opinion that something I have hard data on. The Mesa/NIR-based drivers in particular are very nice to work with!