@Nick Smith Lets say you've got a program that is manipulating data in an array. If that array exists on your computer in memory, your language can express iterating over that array as a trivial concept (for loops, streams, sequences, take your pick). What constructs do you have to use if part of that array is in another machine, or in a database, etc? The language and its view of the world completely breaks down. You now have to spend X LOC writing clunky code that's abstractions over some OS syscalls to get that array close to hand so that the language can resume (and you can't resume unless you can bring the array close to hand!). As humans we can express "part of this array is _over there_", but the languages we use have no concept of "_over there_", there is only here. It's not a problem about abstracting over the oddities of networks, though that does play a part, its a problem of expressing over there in a computer language. This is all a rant to say that I think distributed systems are entirely a language problem 😛

A lot of Unix’s original success derived from co-evolving the OS syscalls with the language. Abstractions over syscalls don’t have to be clunky.

Sorry, I was being dramatic; I meant clunky relative to the array.map(...) code you would normally be writing. The Http/IPC calls to get data local will always be more complex than array[i+1], which was like, the #1 design priority for C

Actually, the excellent Chapel project at Cray, run by Brad Chamberlain, has solved in a very thorough manner the issue of iterating efficiently across arrays that are distributed. The Chapel language was purpose built to provide big data with a means of conveniently accessing data that is spread across compute clusters. There are many subtleties to this ostensibly simple feature request, and i think you will be impressed with Chapel. It is not a particularly convenient language for writing graphical interactive software, but then what systems optimized for distributed systems are?