Thanks. [1] contains an interesting discussion of Sequoia, and why it was considered a failed experiment, leading to Legion ][2], its successor.
The Regent language (Legion is Regent's runtime) is yet another async task-graph-based PGAS language/run-time, similar to, e.g., HPX, but leaving out what in my opinion made Sequoia interesting (e.g. the memory hierarchy abstraction capabilities).
This is probably quite different from your use case.
For doing a dot-product on the GPU, you need to take your vectors in global memory, and:
- split them into chunks that will be processed by thread blocks
- allocate shared memory for storing partial reductions from warps within a thread-block
- decide how many elements a thread operates on, and allocate enough registers within a thread
- do thread-block reductions on shared memory
- communicate thread-block reduction to global memory
- do a final inter-thread block reduction
A sufficiently-smart compiler can take a:
sum = 0.
for x,y in zip(x,y): sum += x+y
But if you are not able to implement the above in the language, it suffices for the user to run into the need to do so once (e.g. your compiler does not optimize their slightly different reduction efficiently), for the value proposition of your language to suffer a huge hit (if I need to learn CUDA anyways, I might just use CUDA from the start; if I don't need performance, I wouldn't be using a super-expensive GPU, etc.).
This is IMO why CUDA is successful, and pretty much all other languages are not, maybe with the exception of OpenACC which has great CUDA interop (so you can start with OpenACC, and use cuda inline for a single kernel, if you need to).