No. Language was not a problem at all. For people who are accustomed to writing code for modern CPUs, switching languages is no big deal: they all perform as go

No. Language was not a problem at all. For people who are accustomed to writing code for modern CPUs, switching languages is no big deal: they all perform as good as compiler and language runtime are designed. That's because CPUs are forgiving to the programmer, and they employ a lot of techniques to run _arbitrary_ code well. GPUs were super "dumb" at the time, but they had truckload of ALUs, and people wanted to maximize usage of ALUs at all costs. Because running a power-hungry cluster on a task for one month or two months actually makes a lot of difference. So you choose a tool that gives _the most control over tricky hardware_. And this is going to be a vendor-provided tool. So, if CUDA was based on Forth or Unlambda instead of C++, people would've used it anyways. OpenCL advertised "write once, run everywhere" approach, it was completely bonkers when it comes to HPC. Optimizations that one applies on different hardware make code look completely different. It has its niche, but not in HPC. I am no longer in this industry, so maybe things changed. But at the time, some teams picked up OpenCL and quickly dropped, as it didn't give enough bang for a buck, and tooling didn't compare with rather polished CUDA stuff.