A Q&A With Opa Creator Henri Binsztok

I recently attended the PhillyETE conference and there were a number of interesting talks. In particualar, I was a big fan of the talk from Alex Payne regarding Emerging Programming Languages. One of the languages that I found interesting, Opa, seemed more than just a language, and conveniently someone emailed me about it. That someone is Henri Binsztok, the CEO of mlstate.com and creator of Opa. Given that Opa is probably unknown to many readers, I figured I would get some basic questions answered by Henri. Henri described Opa in one line, “It puts together the actors of Erlang, the type safety of ML and lots of automation to make web app development easy.”

Why a new language for web development?

Henri: This a very good question, as many developers appreciate the comfort of a well-known programming language. So, to rephrase it just a bit: Why a new language, and not a framework? Because the things Opa do are easier for developers than what a framework on an existing language can provide. For instance, the typed “power rangers” of Opa is a unique language feature that makes strong static typing easy to use for everybody.

You can write in Opa:
x = { field: y, another: z }
a = { field: b }

Then write a function that accesses x.field or a.field, with type-safety and without prior annotation or definition. This alone makes a new language worthwhile! And although it may look simple to implement, it’s a very complex problem since it breaks type principality. We see frameworks as an intermediate step between two generations of a language: one that is too generic and doesn’t quite match the domain, and one that was designed for this domain, but doesn’t exist yet at the time the framework is started.
And we made Opa that new generation for web development.

How does Opa work?

Henri: Opa is basically two things: A compiler that does many things and a runtime platform. The compiler mostly:

  1. Type checks the code for the whole application
  2. If typing is correct, identifies which parts of the application run on the server, and which parts run on the client (we call this step: “slicing”)
  3. Translates all client-side code from Opa to JavaScript
  4. Compiles all server-side code from Opa to native code
  5. Generates a standalone application binary by putting together the runtime platform as a library, the native code of the app, and the client-side resources (including the generated JavaScript).

The runtime platform performs the tasks of a web server, an application server, include the standard library of Opa (which you can consult at http://doc.opalang.org/api) and even has its own database engine. For the latter, Opa also has a very advanced support for MongoDb which makes it the preferred database for production-grade Opa applications.

What does the typical application developer need to do differently?

Henri: The only thing you have to learn to develop in Opa is the Opa language itself. All aspects (front-end code, back-end code, database code) are written in Opa and there is almost no configuration left to do. Compared to writing JavaScript and especially Ajax calls (or continuations by hand with Node.js) and Tomcat/Java, Opa is much easier.

Why are Actors (and your reference to Erlang) important?

Henri: Erlang is a fantastic example of why new programming languages bring fresh air. The actors model is an essential part in modern (social) web applications. All the “real-time” web features, and client-to-client communication in general is programmed easily with actors. Web chats, games, social sharing applications, etc. rely on these features. In Opa, we make it simpler than ever:

  1. Define the types of messages: type message = this (or that)
  2. Create the actor: instance = Network.network(message) Network.cloud(“name”)
  3. Program the behavior of messages received: Network.add_callback(callback, instance)
  4. Send messages: Network.broadcast(message, instance)

You can create as many actors as you want, between clients and servers, different servers, or different clients.

If static typing is so good, why not just move to Java on the server?

Henri: The typing system of Opa is more advanced than that of Java, and the core of the language is tailored for the web application features. For instance, Java will only get closures in Java 7 while this has been a key feature of Opa since the early prototypes 5 years ago. That said, Java has a vibrant ecosystem and it would make sense to support the JVM as one the platforms for Opa. The same Opa application could be then compiled either to its current native backend, or the JVM. It’s a complex task – but we are looking for contributors in that space to make things happen faster!

How does someone get started? Interesting links, documentation and tutorials?

Henri: There are more and more links and tutorials about Opa on the web. But as a general resource, I’d suggest to start from http://doc.opalang.org which hosts a manual, the API documentation and a handy reference card. Adam Koprowski and I are now busy writing the forthcoming book “Hands on Opa” that will be published by O’Reilly this summer!

What is the one thing (or 3 things) that make Opa stand out for web development?

Henri: It’s always hard to sum up such an amount of work in one thing. But I’d say it’s that we refined the approach of what a web application programming language should be to an unprecedented extent. Try it out and make your own opinion!

Related articles
Enhanced by Zemanta