Hacker News new | ask | show | jobs
by tqs 5171 days ago
The innovation here is using the type system to determine whether code should be executed on the client or the server. Contrast this with writing code manually for node and the browser. In this case, though it's all javascript, the programmer must explicitly divide the code for the server and the client. Or contrast with Meteor. Here there is a bit more code sharing, but the programmer still needs to think about client vs server (by checking `Meteor.is_client` and `Meteor.is_server` where appropriate).

In Opa (as I understand it--I haven't used it), the programmer can be explicit about where code execution should occur, but the compiler can also infer where it should occur, determine the best place to put the "data boundary", and warn the programmer if code is executed in an unsafe context.

For "traditional" next-gen web apps, it's a tough call that this is enough of a win to warrant learning a new language. Further, because this style of server-client programming is pretty immature, programmers may want to have tight control over where code is run.

However, I think this is very important work for the future of distributed computing. In particular, consider if we are ever to move from the web's dominant server-client architecture to a more fluid peer-to-peer model, with code moving from client to client where appropriate (i.e. mobile agents). For example, say my phone needs to grab some data from my laptop, but rather than have the laptop send all the raw data to my phone and have my phone process it, the system figures out that it would be more efficient for my phone to send code to my laptop, have the laptop process the data locally, then send the processed data back to my phone.

To be able to make inferences like in that example, I think we will need to use approaches like Opa.

1 comments

> For example, say my phone needs to grab some data from my laptop, but rather than have the laptop send all the raw data to my phone and have my phone process it, the system figures out that it would be more efficient for my phone to send code to my laptop, have the laptop process the data locally, then send the processed data back to my phone.

I've been romanticizing this kind of dynamic client-hopping execution in my head for a long time, and I even tried to implement it once. The biggest problem is that it's a provably impossible problem to solve! If your language is Turing-complete, it reduces to the halting problem.

You can make guesses (as Opa does) and cover the simple cases with code analysis, but in practice such attempts have devolved into inefficiency and synchronization problems once you start implementing nontrivial systems over fallible interfaces such as the web. It all brings to mind FGCS[1], and how that just didn't work.

[1] http://en.wikipedia.org/wiki/Fifth_generation_computer

What exactly is the problem you are referring to as unsolvable?
The problem of deciding where best to execute code.