How about trying to find errors as early as possible, by for example using the type system? That will not catch everything, but it will catch quite a lot.
You can definitely get a lot out of using better abstractions, as the success of MapReduce has shown. I'll list a few ideas, with the warning that they may be half-baked:
* Strong, stern type checking has always been kind of a pain in the ass, but it's very effective at catching miscellaneous stupid errors. If debugging in the cloud is hard enough, then maybe overbearing type systems are the lesser of two hassles.
* Interactive programming is a big win. One of the best things about Lisp is the REPL, and how well-integrated it is with the editor. (At least, if you use something like SLIME.) If I'm programming on a distributed system, I definitely want to be able to quickly test out my code, preferably in a concurrent environment. You could solve this by having a bunch of servers for this, or with some fancy simulation environment, or a bunch of virtual machines, or something. The point is, I want errors to show up fast.
* Really good log analysis. Ideally, any framework you're using would automatically log everything it does, and then you would use some nice tools to figure out what happened, and where it went wrong. Maybe the Loggly guys will come up with some good stuff.
* Data-flow oriented abstractions like what Apache Pig offers. Pig lets you define a directed acyclic dataflow graph, in which each edge is some operation like "group by field x", or "filter by function f(fields)". It compiles all this into MapReduce jobs and runs them on Hadoop. It's probably a lot harder to mess up a query in Pig than with raw MapReduce, for sufficiently complicated queries. I'm not sure how much of a performance hit you take, though.
That's one of the trade-offs when deciding between a statically or dynamically typed language. Static typing isn't really going to help you with debugging/avoiding concurrency issues, though.
Well, the type system can be used to isolate side effects, thus ruling out large classes of concurrency bugs (especially with threads instead of separate processes or strict message passing (e.g. Erlang)). It can also prove that typing errors cannot occur, whereas with a dynamic language, it is possible for the program to be ill-typed in only certain circumstances (a function could return a different type depending on input). But yes, there are plenty of concurrency issues that are not greatly mitigated by static typing.
