Comment by swiftcoder

> very few languages aside from C++ have good CUDA support

CUDA happens to be (loosely) source-compatible with C++, but I'm not sure that's the same as saying C++ has good CUDA support. The majority of C++ code does not compile to CUDA (although the inverse is often true).

> C++ certainly doesn't achieve that by having its arrays be equivalent to functions "in practice" or in any other sense

The syntax may not be unified, but what else do you think iterators are for? They are an abstraction to let us ignore pesky details like the underlying storage of arrays, and instead treat them like any other generator function. This is perhaps more evident in a language like Python where generators and iterators are entirely interchangeable.

> in Futhark an array type such as [n]f64 explicitly indicates its size (and consequently the valid indices), which can even be extracted at run time. This is not possible with functions

These are specific oddities of Furthark - we have languages (i.e. C/C++) where the size of an array is not knowable, and we have languages where the range of inputs to a function are knowable (at least for numeric inputs, i.e. Ada)

> Futhark imposes restrictions on how functions can be used; for example banning returning them from branches. These restrictions are not (and ought not be!) imposed on arrays

Again, this is a case of Furthark's own design decisions restricting it. This is only a problem because their arrays are carrying around runtime size information - if they didn't have that, one wouldn't be able to usefully return them from branches anyway. Alternately, there are plenty of ML-family languages where you can return a function from a branch.