I wouldn't call one proper CUDA and the other one some dumbed down version. Nvidia really seems to be pushing for these DSLs to be first class within the ecosystem. In some cases probably even more cutting edge than the nvcc frontend, since it's easier to do some experimenting on a new niche package than on the tool everyone relies on.
I believe more and more production code is running kernels which didn't originate from the traditional cuda cpp route.
> I wouldn't call one proper CUDA and the other one some dumbed down version. Nvidia really seems to be pushing for these DSLs to be first class within the ecosystem.
I wouldn't say one is dumbed down either, just different, at least the entrypoints and how you end up using the different solutions.
I'm currently experimenting with cuda-oxide for some new simulations, and managed to keep the entire simulation within just Rust essentially, while going the "traditional" (maybe better term than "proper"?) way I've ended up with a bunch of .cu files and then integrating them (via cudarc usually). Kernels themselves feel the same across both, but the integration clearly makes them different enough that I think it's worth distinguishing them, at least for clarity if nothing else.
If someone else already knew Rust but not C++, wanted to get into CUDA programming, going the cuda-oxide route would probably be easier and more familiar, than cudarc, I'd guess. Personally I'm not sure what route I prefer yet, both (as always?) have tradeoffs.
I believe more and more production code is running kernels which didn't originate from the traditional cuda cpp route.