What seems to be a pity about most array languages is that in theory, they would be ideal DSL languages for SIMD and MIMD code exploration, but as far as I understand from ArrayCast guests, most are still interpreters at heart focusing on plain CPU execution.
The big problem with using array languages for lower-level SIMD stuff is that that generally requires some amount of typedness, but tacking on types on an array language without ending up with having types be the majority of the syntax and code (or taking up a ton of mental capacity if utilizing very heavy type inference) would be rather non-trivial. And the operations you want for lower-level ops are quite different from the higher-level general-purpose ones too. (and, of course, some interpreters do make good use of SIMD and/or multithreading)
That said, some form of array language more suited for stuff like that is a somewhat common question; maybe one day someone will figure it out.
Vanessa McHale is doing some interesting work on a typed compilable array language, Apple[0].
While we have CUDA being polyglot, it is still pretty much C and C++, or shader languages, hence why I keep thinking why not an array language that is also a kind of shader language DSL.
Oh, another interesting thing is http://beyondloom.com/tools/specialk.html - a simple k DSL for shaders. Though it still follows the shader language paradigm of running the function for each pixel separately, rather than the array language paradigm of taking & returning a list of things to process.
Not exactly the approach your describing, but Futhark[0] offers an alternative to CPU execution, it compiles to CUDA or OpenCL to run on GPU (or multi-threaded CPU).
That one I am aware of, as language geek, I am always curious to GPU alternatives that aren't always the same old story only C and C++ get to party, which is actually an advantage of CUDA's polyglot approach.
