Alternatives can only become one, if they support the same set of C, C++, Fortran, and PTX compiler backends, with similar level of IDE integration, grapical GPGPU debugging, and frameworks.
Until then they are wannabe alternatives, for a subset of use cases, with lesser tooling.
It always feels like those proposing CUDA alternatives don't understand what they are trying to replace, and that is already the first error.
Are you proposing that they should be doing stuff like frameworks and ide integration all by themselves or are you saying they should magically make a community appear to make them?
The product comes before the community (unless you have insane marketing money)
> Alternatives are supposed to cover all uses case
I can't think of a single tech product where feature parity was a driver for growth. If all you have is parity, then all you compete on is lower price.
Usually, some advantage (better/safer/faster/easier) makes a difference for a few important use cases (good examples were early, feature-incomplete no-sql databases that excelled in one use case that existing SQL servers did not). That advantage hasn't emerged yet, so no community has developed.
Until then they are wannabe alternatives, for a subset of use cases, with lesser tooling.
It always feels like those proposing CUDA alternatives don't understand what they are trying to replace, and that is already the first error.