Language of the Month: Opa

I believe that's part of Opa's evolution in the two years since this article first appeared.

I have noticed a discrepancy in the information provided here and in http://en.wikipedia.org/wik... about the compiler's result - here the result is an executable with extension .exe, in the wikipedia document the compile steps results in an 'executable' .js file.

As for CSS and similar resources Opa has a special "development" mode where such resources are mapped to the file system, can be edited (with immediate changes in the running application) and only then the app can be recompiled to embed those changed files. [http://doc.opalang.org/inde..., http://blog.opalang.org/201...]
As for the code Opa supports a plug-in mechanism which allows linking against other libraries, which can be written either in Opa or in other languages (JS, C, Ocaml), [http://doc.opalang.org/inde...].

How are external dependencies managed?
Having evreything in one deployment package is nice, but we've been here before, and often it's essential to be able to swap out a particular sub-component (library, DLL, SO, etc.) for a newer (fixed) version. Same goes for other assets (CSS, etc.).
To have to rebuild the whole unit just for a CSS change seems extreme, or have I missed something?

WT achieves this using C++.

Apart from Opa I think there is Node.js and Ur/web that are trying to do that. But indeed, there does not seem to be a *popular* language (Ruby on Rails aside) using this approach. Of course my hopes are high that Opa will fit this bill one day :).

Weird that after the success of Ruby on Rails, no other language has embraced this approach. That is, of using one language for all three tiers.