We've heard this all before, though. 40 years ago, Machine Code was where it was it, and people scoffed at those who were lazy enough to use an assembler. Then Assembly was where it was at, and the abstraction that C provided was leaky and poor, and compiled code could never be as good as hand-written assembly coded directly against the individual processor instruction set.
The problem with this argument is that it applies just as much in the two above examples as it does in this one, and it's clear that C has really taken off. Making good abstractions is damn hard, and the law of leaky abstractions is brutal, but the success of C, and even Java (a virtual machine on top of a compiler on top of a assembler on top of the machine!) shows that it can be done.
I'm pretty happy I can write code in C and can't imagine worrying about things like different instruction sets, registers, L1/L2 caches, etc. just for a basic "hello world". Perhaps in the future, people will think it equally crazy that we had to worry about details like what database we use, how we serialize data over the wire, manually creating ajax endpoints, etc.. Perhaps they'll let the compiler do all this work and only dive into manually fiddle with this stuff when they need to squeeze the last 10% performance out of the system, just as C programmers sometimes drop into ASM today.
It doesn't -- C is analogous to the coffeescript case; it's not at all like Opa. It's the minimal portable abstraction over digital computers. Given some C code, it's not hard to predict roughly what instructions it compiles into. It precisely illustrates the point, because there were dozens of more complicated abstractions (languages) that failed. They claimed to do more for you, but what they did conflicted with reality and failed (in that era, usually because it was hard to reason about performance). C is humble and makes few assumptions.
"Abstraction is layering ignorance on top of reality" -- Richard Gabriel
My opinion is that anything which tries to abstract network communication and make it "transparent" is going to run in to problems at scale. For some reason there is this endless desire of programmers to extend their type system across the wire. It's been tried so many times.
The goal of Opa appears to be "transparency" as discussed here -- making distributed computing look like single-machine computing. This was also the goal of GWT.
Doesn't the C compiler do all sorts of optimization magic that makes the output of the compiler sometimes hard to predict? C is also not the only language that succeeded; C++ and Java are doing pretty well, and I've used them quite alot without delving into the sausage factory of GCC/javac. Scala is doing pretty well too, with it's 20 stage compilation process!
I disagree that anything trying to abstract away network communications will fail; I doubt that every engineer at google is a full-stack expert who single-handedly sets up a massive-scale service every day by hand. More likely, they have developed a set of somewhat-reusable abstractions that they can build upon for a variety of services. Hadoop is another example where the whole network thing is abstracted away. Amazon S3/Cloudfront is yet another. Difficult, but not impossible.
Perhaps Opa is trying to be the minimal portable abstraction over a full-stack service. I know GWT tried to be the same thing and failed, but one failure doesn't mean you give up, and I'm glad they're still trying.
It's true that a C compiler does that now, but it didn't 40 years ago. Platforms that start really complex don't have a hope of lasting -- they collapse before they get to the stage of old and hairy.
I think this is an important point -- systems that last have to start really simple.
The Web was laughably simple at first. HTTP 1.0 was roughly: open a TCP connection, send a URL, get the document back, close the connection. It was WAY simpler than many contemporary hypertext solutions.
Unix was also WAY simpler than its contemporaries. Linux is old and hairy now, but that's just how things age without falling apart. They have to accomodate many different people's (sometimes broken) mental models under one roof. A system like Opa seems like it can only accomodate the mental model of its creators, and thus won't age gracefully.
C++ despite being huge has some modesty: it respected people's existing C code and didn't "cover it up". Plenty of people write C with classes still and that's actually a feature. Opa seems like it "covers up" what's underneath.
Java is kind of an exception to the adoption curve because it had huge marketing behind it like no other language did. But I think Java 1.0 was still pretty darn simple. It was a very small language. I'll grant that Java did try to cover up the OS. I think this limited its widespread application, but it's admittedly still massively popular for certain things. You couldn't do async I/O in Java for awhile, nor could you do things like make a Windows shortcut on the desktop.
Hadoop, being based on the MapReduce abstraction, does indeed pretty successfully allow the programmer to ignore the network. The fairly large restriction of being able to write 2 pure functions -- map and reduce -- is what allows this (it allows retries without affecting correctness, etc.). In a way this proves the point. You can't write arbitrary procedural/stateful code (in Opa or any other language) and distribute it over the network at scale. I'll go as far as to claim that this problem is unsolvable in a fundamental sense, like the halting problem is unsolvable.
Now maybe Opa introduces some restrictions in their model that help with distribution that I don't know about, but in general I am skeptical of the "write all your code in this one clean language with our nice model and we'll figure out the rest automatically with our hyper-optimized advanced technology". We've heard it before.
I honestly don't know why as a programmer you would want to ignore the distinction of code running on the client or the server. I'm all for sharing (some) code, as Node.js allows, but it should be obvious in any application whether a code path is running on the client or the server, and you shouldn't need a compiler to figure it out. That kind of coupling is crazy.
The problem with this argument is that it applies just as much in the two above examples as it does in this one, and it's clear that C has really taken off. Making good abstractions is damn hard, and the law of leaky abstractions is brutal, but the success of C, and even Java (a virtual machine on top of a compiler on top of a assembler on top of the machine!) shows that it can be done.
I'm pretty happy I can write code in C and can't imagine worrying about things like different instruction sets, registers, L1/L2 caches, etc. just for a basic "hello world". Perhaps in the future, people will think it equally crazy that we had to worry about details like what database we use, how we serialize data over the wire, manually creating ajax endpoints, etc.. Perhaps they'll let the compiler do all this work and only dive into manually fiddle with this stuff when they need to squeeze the last 10% performance out of the system, just as C programmers sometimes drop into ASM today.