The Opa Language(opalang.org)
opalang.org
The Opa Language
http://opalang.org/
13 comments
Mainstream developers often make such a mistake as they chase fads: just don't worry about them. Your focus is a niche with less press anyway. My specialty high assurance systems & security. I like your language because it's safe like ML, extends that to Web stuff, doesn't treat DB's like an afterthought, and integrates whole stack without the mess of mainstream stuff. I'd expect Opa apps to be more robust than average web app. The only thing I didn't like is you porting the backend to Javascript, a step backward in assurance. Hard enough to do an EAL7, JavaCard VM or non-optimizing C compiler. A Javascript implementation might be a PhD's worth of work. Yet, I understand why you did it and it made some sense for your market. I'm sure people wanting more assurance could always modify the backend to target something simpler, right?
Your main competition, that I see, are Ur/Web and the Ocaml/Haskell frameworks. I recommend that you continue doing what you're doing while copying any great things you see in those communities along the way. Especially ways to leverage type system to prevent problems. I think just good marketing, library support, fixing some of what people are griping about, and some major success stories in the media is all you need. Best wishes on your work as it's one of rare few that leans toward a Correct-by-Construction approach to web applications. Need more of those.
Your main competition, that I see, are Ur/Web and the Ocaml/Haskell frameworks. I recommend that you continue doing what you're doing while copying any great things you see in those communities along the way. Especially ways to leverage type system to prevent problems. I think just good marketing, library support, fixing some of what people are griping about, and some major success stories in the media is all you need. Best wishes on your work as it's one of rare few that leans toward a Correct-by-Construction approach to web applications. Need more of those.
I couldn't agree more! Although biased, I think that Opa is the easier of those technologies to learn and master for developers. And we also have more flexibility due to our compiler (vs frameworks). We have been rightfully compared to Ur/Web since the beginning. Adam Chlipala is an outstanding scientist and his work is definitely of high quality, maybe more academic.
Note that we have other experimental backends available, although not in the open source release (yet). I am also interested in compiling to MirageOS -- we have all the mechanisms in place in Opa to do that easily, namely one called the "Bypass Standard Library" (BSL). I just uploaded one draft paper written at MLstate about the BSL: https://www.scribd.com/doc/271277920/Opa-BSL-Bypass-Standard...
Note that we have other experimental backends available, although not in the open source release (yet). I am also interested in compiling to MirageOS -- we have all the mechanisms in place in Opa to do that easily, namely one called the "Bypass Standard Library" (BSL). I just uploaded one draft paper written at MLstate about the BSL: https://www.scribd.com/doc/271277920/Opa-BSL-Bypass-Standard...
I was gonna suggest MirageOS but held off. Since you said it, by all means do the port. Ill look at the stuff in the link when Im on desktop.
As someone who has tried to replace gmail with Zimbra, Roundcube and others over the years, PEPS looks interesting. How production ready is it? What features would you say it's lacking?
Thanks for your message.
We maintain a roadmap: https://github.com/MLstate/PEPS/wiki/Roadmap
Thanks to Opa (possibly due to that fact that we know how to use it at its best), we are able to develop features very quickly. I would say that what we need most is to optimize the UX and little details that matter to refine them over time. But overall, I think we can go technically much farther that Zimbra/Roundcube. But to achieve more popularity, we will need to beef up some marketing aspects!
We maintain a roadmap: https://github.com/MLstate/PEPS/wiki/Roadmap
Thanks to Opa (possibly due to that fact that we know how to use it at its best), we are able to develop features very quickly. I would say that what we need most is to optimize the UX and little details that matter to refine them over time. But overall, I think we can go technically much farther that Zimbra/Roundcube. But to achieve more popularity, we will need to beef up some marketing aspects!
I'll be honest, I thought this project was dead. How is Opa still relevant and what, if anything, are they doing to attract new developers today?
Same here -- I found this extremely interesting about 4 years ago and did some playing around with it, but the project seemed to drop off the map after awhile.
Every German speaker will read this as "The Grandpa Language".
"Opa" is very easy to learn to pronounce, and not surprisingly is used in many languages to get the attention of some of the more important people a young child may need help from. Many many languages use ma and pa/ba for parents, and I'm not surprised that opa is used for other relatives by many languages.
I'm not Korean, but my understanding is one reading might be "Mister Language". Several of my Korean friends address me as "Karl Oppa" or just "Oppa". (Yes, "opa" isn't the standard Romanization, and the word order isn't correct.)
In Korean "oppa" is the word for older brother used by a younger sister, and by extension, an honorific used by a younger woman to show respect for an older man. (When my Korean friends meet someone new, they quickly figure out who's older, even by just one year, in order to figure out who's supposed to use the honorific addresses.)
Imagine if in English, we only used Mr. and Ms. when talking to someone who's chronologically older, and had different forms depending on if the speaker is male or female, and furthermore it was considered very rude not to use the title where appropriate. Oppa is kind of the word for "mister" used by women, but is mandatory in many more cases than would be expected in English.
I'm not Korean, but my understanding is one reading might be "Mister Language". Several of my Korean friends address me as "Karl Oppa" or just "Oppa". (Yes, "opa" isn't the standard Romanization, and the word order isn't correct.)
In Korean "oppa" is the word for older brother used by a younger sister, and by extension, an honorific used by a younger woman to show respect for an older man. (When my Korean friends meet someone new, they quickly figure out who's older, even by just one year, in order to figure out who's supposed to use the honorific addresses.)
Imagine if in English, we only used Mr. and Ms. when talking to someone who's chronologically older, and had different forms depending on if the speaker is male or female, and furthermore it was considered very rude not to use the title where appropriate. Oppa is kind of the word for "mister" used by women, but is mandatory in many more cases than would be expected in English.
It always irks me, I don't know when this trend started but when I moved away from Korea in the mid 90s as a young child this was strictly a honorific for older brother from a younger sister OR maybe I was just unaware of the trend because I was a kid.
So I get grossed out when a Korean girl calls me oppa and I have expressed my discomfort which was met with a cold response (I guess they really like calling older men oppa), part of the reason I never date younger Korean women. That and the whole 'mister' or aekyo (adult women emulating an infant) shit I find very creepy and unattractive. There's this national inclination for young women, sort of like Japan's obsession with schoolgirls.
On the other hand, being called 'ajusshi' which doesn't carry the same affection as 'oppa' and intended for much older men and some Korean men take offense when addressed as 'ajusshi' but less so than Korean women who go apeshit when I made the mistake of calling them 'ajumma'.
on an offtopic side note, Oppai in Japanese means tits.
So I get grossed out when a Korean girl calls me oppa and I have expressed my discomfort which was met with a cold response (I guess they really like calling older men oppa), part of the reason I never date younger Korean women. That and the whole 'mister' or aekyo (adult women emulating an infant) shit I find very creepy and unattractive. There's this national inclination for young women, sort of like Japan's obsession with schoolgirls.
On the other hand, being called 'ajusshi' which doesn't carry the same affection as 'oppa' and intended for much older men and some Korean men take offense when addressed as 'ajusshi' but less so than Korean women who go apeshit when I made the mistake of calling them 'ajumma'.
on an offtopic side note, Oppai in Japanese means tits.
> Imagine if in English, we only used Mr. and Ms. when talking to someone who's chronologically older, and had different forms depending on if the speaker is male or female, and furthermore it was considered very rude not to use the title where appropriate.
In parts of the South, you’re still expected to use “sir” and “ma’am”, particularly with strangers. Most speakers find this a bit old-fashioned or excessively polite, though.
In parts of the South, you’re still expected to use “sir” and “ma’am”, particularly with strangers. Most speakers find this a bit old-fashioned or excessively polite, though.
In Bulgarian it could be translated as "oops! language". Really, really unfortunate.
And Greeks are dancing to it.
OPA in Italian is IPO in English (actually not only Initial, any of them). Definitely a good omen for startups :-)
On the other hand, it means Takeover (of a public company) in Portuguese. (OPA = Public Offer of Acquisition)
if you can do all the shiny web things by writing grandpa code, this might be a good thing :)
That is really unfortunate.
A few impressions:
- Seems like the language forgot about objects (they seem to be used as collections or namespaces) - which is surprising given it's JavaScript underneath.
- It also seems like the database functionality is so embedded within the language that using it would sacrifice a lot of control and would become a huge lock-in liability.
- Everything is too abstracted. I must admit my first real programming experience was in PHP, and now that I've done a lot of things in Node.js and other languages I really appreciate being able to do some more things at a lower-level of abstraction (PHP ends up being a glorified templating language usually).
- Edit: Oh, and please can someone find a way to nicely get rid of these JSX-esque syntax additions and just start using ES6 template strings instead. All these extra compilation steps make things so much more complicated and third-party reliant than they need be.
- Seems like the language forgot about objects (they seem to be used as collections or namespaces) - which is surprising given it's JavaScript underneath.
- It also seems like the database functionality is so embedded within the language that using it would sacrifice a lot of control and would become a huge lock-in liability.
- Everything is too abstracted. I must admit my first real programming experience was in PHP, and now that I've done a lot of things in Node.js and other languages I really appreciate being able to do some more things at a lower-level of abstraction (PHP ends up being a glorified templating language usually).
- Edit: Oh, and please can someone find a way to nicely get rid of these JSX-esque syntax additions and just start using ES6 template strings instead. All these extra compilation steps make things so much more complicated and third-party reliant than they need be.
> make things so much more complicated
Simple pre-processing and code-to-code transformation is typical in many different languages and environments. Pretty much every time you start a Java or C++ project within some IDE you're essentially generating a lot of code automatically.
And in the case of various JS preprocessors/transpilers it's not even that complicated. It's mostly trivial transformations, which in more capable languages would be expressed as macros, f-exprs or something like that. Maybe try writing your transpiler sometime? It'll take a weekend, and you'll see how easy and simple it is.
> Everything is too abstracted.
That's only because of your background. ASP.NET or GWT guys would not agree, I imagine.
> it would sacrifice a lot of control and would become a huge lock-in liability.
Control over what exactly? You still have an external database you need to manage. You handle backups, schema migrations and so on. I'd say Opa's abstraction of data storage is on par with "normal" ORMs (like Django ORM) in terms of flexibility/power ratio.
I don't see a lock-in potential here, as long as data store used by Opa is available to other languages and environments. You can always just load the raw data directly from DB and do anything you want with them. Would be another story if Opa used in-memory, built-in in-process data storage (which is an approach I quite like) but it doesn't.
Simple pre-processing and code-to-code transformation is typical in many different languages and environments. Pretty much every time you start a Java or C++ project within some IDE you're essentially generating a lot of code automatically.
And in the case of various JS preprocessors/transpilers it's not even that complicated. It's mostly trivial transformations, which in more capable languages would be expressed as macros, f-exprs or something like that. Maybe try writing your transpiler sometime? It'll take a weekend, and you'll see how easy and simple it is.
> Everything is too abstracted.
That's only because of your background. ASP.NET or GWT guys would not agree, I imagine.
> it would sacrifice a lot of control and would become a huge lock-in liability.
Control over what exactly? You still have an external database you need to manage. You handle backups, schema migrations and so on. I'd say Opa's abstraction of data storage is on par with "normal" ORMs (like Django ORM) in terms of flexibility/power ratio.
I don't see a lock-in potential here, as long as data store used by Opa is available to other languages and environments. You can always just load the raw data directly from DB and do anything you want with them. Would be another story if Opa used in-memory, built-in in-process data storage (which is an approach I quite like) but it doesn't.
> Simple pre-processing and code-to-code transformation is typical in many different languages and environments.
True, but I suppose it's still nice to avoid as many unnecessary steps in deployment as possible.
> That's only because of your background. ASP.NET or GWT guys would not agree, I imagine.
Well, there are good and bad abstractions. Many abstractions get in the way eventually if you're doing anything non-trivial.
True, but I suppose it's still nice to avoid as many unnecessary steps in deployment as possible.
> That's only because of your background. ASP.NET or GWT guys would not agree, I imagine.
Well, there are good and bad abstractions. Many abstractions get in the way eventually if you're doing anything non-trivial.
Very nice work pulling this sort of thing up - but honestly? This looks terrible to actually use in code.
Even if they do commit to working on this language - and it offers advantages over Meteor (which it looks to be inspired a lot from) - they have a lot of design choices I don't understand:
- Inventing a new language over JS is problematic, a dependency, and you don't get goodies as they land in JS.
- The fact IO is implicit and not explicit means you don't know where you're paying - and is a very leaky abstraction.
- jQuery as a default part of the standard library? Really?
- Anything that "automates the database" terrifies me, anything that wraps PostgreSQL and MongoDB with the same wrapper means I'm paying for impedence mismatch _somewhere_ but they're not telling me where.
- Their "MVC support" section is really about scaffolding, and MVC on the server doesn't make sense anyway in this scenario.
I like the JSXish'ness of some of it but honestly not sure why anyone would use it - the fact there are no strong backing companies is also worrying.
That said - that's just my impression so as always I recommend you try it yourself rather than take my criticism :)
Even if they do commit to working on this language - and it offers advantages over Meteor (which it looks to be inspired a lot from) - they have a lot of design choices I don't understand:
- Inventing a new language over JS is problematic, a dependency, and you don't get goodies as they land in JS.
- The fact IO is implicit and not explicit means you don't know where you're paying - and is a very leaky abstraction.
- jQuery as a default part of the standard library? Really?
- Anything that "automates the database" terrifies me, anything that wraps PostgreSQL and MongoDB with the same wrapper means I'm paying for impedence mismatch _somewhere_ but they're not telling me where.
- Their "MVC support" section is really about scaffolding, and MVC on the server doesn't make sense anyway in this scenario.
I like the JSXish'ness of some of it but honestly not sure why anyone would use it - the fact there are no strong backing companies is also worrying.
That said - that's just my impression so as always I recommend you try it yourself rather than take my criticism :)
I want to counter your criticism with this:
I think having XHTML as a defined type is a stroke of genius, at the risk of hyperbole. No quoting html fragments?! Damn. Wish I'd thought of that.
I'd say it's because of this requirement that they couldn't use Javascript. And inventing a new language over JS is problematic. I won't even learn coffeescript and that's everywhere. You're not going to get me to learn Opa, sorry. Maybe they should have made it a very thin preprocessor where you get to inspect the JS...
Object Relational Mapping and Object Document/Graph Mapping is fine so long as they're not the same mapping :) and so long as you get to inspect the SQL or MongoDB QL...
Not sure what you mean by "and MVC on the server doesn't make sense anyway in this scenario" We're all familiar with MVC scaffolding from Rails by now, aren't we?
I think having XHTML as a defined type is a stroke of genius, at the risk of hyperbole. No quoting html fragments?! Damn. Wish I'd thought of that.
I'd say it's because of this requirement that they couldn't use Javascript. And inventing a new language over JS is problematic. I won't even learn coffeescript and that's everywhere. You're not going to get me to learn Opa, sorry. Maybe they should have made it a very thin preprocessor where you get to inspect the JS...
Object Relational Mapping and Object Document/Graph Mapping is fine so long as they're not the same mapping :) and so long as you get to inspect the SQL or MongoDB QL...
Not sure what you mean by "and MVC on the server doesn't make sense anyway in this scenario" We're all familiar with MVC scaffolding from Rails by now, aren't we?
> I won't even learn CoffeeScript and that's everywhere.
Could you please explain why is that? I'm honestly asking - my hobby of learning languages (https://klibert.pl/articles/langs.html) makes me completely unable to understand opinions such as yours here.
Opa once implemented an ML-like language, which I liked better than the current JS-like thing. They moved to JS because of two reasons, IIRC: to get a runtime for free (Node) and to be "more familiar to more developers".
Besides syntax, Opa offers quite a lot of benefits on a language level. Static typing with inference and statically typed HTML - this means that code that isn't safe in terms of HTML injections does not compile at all! Executing the same code on both backend and frontend, built-in database layer and a whole lot of helpers and tools for creating SPAs.
At first I thought Opa is something like Seaside in Smalltalk or Nagare in Python, but it is unique in that it lets you write client-side code without much hassle, which is rather hard in other frameworks.
Could you please explain why is that? I'm honestly asking - my hobby of learning languages (https://klibert.pl/articles/langs.html) makes me completely unable to understand opinions such as yours here.
Opa once implemented an ML-like language, which I liked better than the current JS-like thing. They moved to JS because of two reasons, IIRC: to get a runtime for free (Node) and to be "more familiar to more developers".
Besides syntax, Opa offers quite a lot of benefits on a language level. Static typing with inference and statically typed HTML - this means that code that isn't safe in terms of HTML injections does not compile at all! Executing the same code on both backend and frontend, built-in database layer and a whole lot of helpers and tools for creating SPAs.
At first I thought Opa is something like Seaside in Smalltalk or Nagare in Python, but it is unique in that it lets you write client-side code without much hassle, which is rather hard in other frameworks.
I can't answer for igravious, but I can answer for me.
I'm not interested in learning Coffeescript because it doesn't do anything that javascript can't do, by definition, and it seems to me that my time would be better spent practicing more javascript (10,000 hours and all that).
I get that there's some benefit to hopping around languages, learning from the different paradigms, but there's also benefit from going deep on a single language. Some of the stuff I've seen people do in js is amazing and I'd like to get that kind of mastery. I don't think learning Coffeescript will help with that.
I also find that whole "I can code in 12 different languages" a bit shallow. Yes, I can code in 12 different languages, but can I do it well? Have I mastered those languages, or am I just surfing the shallows of each, unable to really get the most out of them?
I'd prefer to pick, say, three languages, at most, and really learn them. JS is going to be one of those languages because browser, I'm still trying to work out the others but Coffeescript is definitely out.
I'm not interested in learning Coffeescript because it doesn't do anything that javascript can't do, by definition, and it seems to me that my time would be better spent practicing more javascript (10,000 hours and all that).
I get that there's some benefit to hopping around languages, learning from the different paradigms, but there's also benefit from going deep on a single language. Some of the stuff I've seen people do in js is amazing and I'd like to get that kind of mastery. I don't think learning Coffeescript will help with that.
I also find that whole "I can code in 12 different languages" a bit shallow. Yes, I can code in 12 different languages, but can I do it well? Have I mastered those languages, or am I just surfing the shallows of each, unable to really get the most out of them?
I'd prefer to pick, say, three languages, at most, and really learn them. JS is going to be one of those languages because browser, I'm still trying to work out the others but Coffeescript is definitely out.
> I also find that whole "I can code in 12 different languages" a bit shallow.
It's 83 in my case... (I'm joking: obviously I didn't write much code in most mentioned languages. But I wrote at least something in the 100-1000 loc range in most of them, I think).
> Have I mastered those languages, or am I just surfing the shallows of each, unable to get the most out of them?
That's only a question you ask yourself at the beginning. You stop doubting your skills and knowledge in different languages around a decade into learning about them. Well, that's how it worked for me.
> and it seems that my time would be better spent practicing more javascript (10,000 hours and all that).
Been there, done that (metaphorical 10000 hours). Four times over with C++, PHP, Python, JavaScript. Then Erlang, and after that, the time needed to learn most of almost any language was significantly reduced.
> I'd prefer to pick, say, three languages, at most, and really learn them.
Again, been there, years ago. Programming - for me - is a life-long career choice, which means I still have 3-4 decades of coding ahead of me. With a solid 10+ years of experience already I know that staying too long with one tech causes boredom; the issue is how to pick the next tech? I figured I'd need to learn quite a lot of them to make informed choices, and so I focused on this. I don't want to stay with a single tech for too long.
It's 83 in my case... (I'm joking: obviously I didn't write much code in most mentioned languages. But I wrote at least something in the 100-1000 loc range in most of them, I think).
> Have I mastered those languages, or am I just surfing the shallows of each, unable to get the most out of them?
That's only a question you ask yourself at the beginning. You stop doubting your skills and knowledge in different languages around a decade into learning about them. Well, that's how it worked for me.
> and it seems that my time would be better spent practicing more javascript (10,000 hours and all that).
Been there, done that (metaphorical 10000 hours). Four times over with C++, PHP, Python, JavaScript. Then Erlang, and after that, the time needed to learn most of almost any language was significantly reduced.
> I'd prefer to pick, say, three languages, at most, and really learn them.
Again, been there, years ago. Programming - for me - is a life-long career choice, which means I still have 3-4 decades of coding ahead of me. With a solid 10+ years of experience already I know that staying too long with one tech causes boredom; the issue is how to pick the next tech? I figured I'd need to learn quite a lot of them to make informed choices, and so I focused on this. I don't want to stay with a single tech for too long.
I should mention that I've been coding for almost 40 years now, and still only feel I've scratched the surface of it.
Did erlang somehow make it easier to learn the additional languages?
I think Erlang was a last drop in a bucket, so to say. Learning it made me finally realize two things: that there are many very different languages and that there is some common, underlying structure to even the most diverse languages.
It sort of went downhill from there :)
It sort of went downhill from there :)
three? maybe four? C, Javascript, (Ruby/Python/Perl), (Haskell/Scheme/Common Lisp)
:)
EDIT: and some assembly variant (ARM,x86,...)? so five?
:)
EDIT: and some assembly variant (ARM,x86,...)? so five?
js kinda covers web coding and dynamic scripted languages at once, and ES6 is a real step forward that's going to open up some new possibilities.
C definitely, if only to be able to read *nix source and do low-level stuff on devices
Then I'd say Clojure, probably, because it covers the JVM as well as the functional group.
C definitely, if only to be able to read *nix source and do low-level stuff on devices
Then I'd say Clojure, probably, because it covers the JVM as well as the functional group.
What's funny is that when I first saw this project years ago, I was excited precisely because it wasn't JavaScript. Basically, I despise JavaScript (thousand burning suns, etc) so something that is definitely not that was exactly what appealed to me and made me want to learn it. (Webassembly is pretty exciting to me now, obviously.)
"Released in June 2011" they have been working on it for a long time, which might also explain some of the choices you pointed out.
Wow, that totally got me, thanks. 2011 definitely explains a lot of the choices like including jQuery and 'almost jsx' syntax. They have some interesting projects with it (the end to end encrypted chat) but I think they might have missed the train. This also explains not mentioning meteor.
Here is an "introduction for coders" on GH - I think it explains it better than the website https://github.com/MLstate/opalang/wiki/A-tour-of-Opa
People interested in secure web development frameworks should definitely check out Ur/Web http://www.impredicative.com/ur/
Don't get me wrong, I feel this is an awesome project, but this looks pretty weird:
#msg = <div>Thank you, user number {/counter}!</div>
> but this looks pretty weird
It's a classic DSL; it's more readable and easier to write than equivalent HTML/JS mix (it's both shorter and has less tokens). Such DSLs are used in some languages extensively, I think the most related is xexpr DSL, for example, http://docs.racket-lang.org/web-server/servlet.html#%28def._... (the part in the code snipped starting with "response/xexpr"). It's in Lisp, which means they could write it without messing with language parser, but the idea is pretty much the same.
It's a classic DSL; it's more readable and easier to write than equivalent HTML/JS mix (it's both shorter and has less tokens). Such DSLs are used in some languages extensively, I think the most related is xexpr DSL, for example, http://docs.racket-lang.org/web-server/servlet.html#%28def._... (the part in the code snipped starting with "response/xexpr"). It's in Lisp, which means they could write it without messing with language parser, but the idea is pretty much the same.
Cool project, and I lke to see people experimenting with new languages and tools.
That said, Opa has a lot of competition. I am thinking of Clojure + Clojurescript, Meteor, Dart, etc. I don't much use Dart, but C+C and Meteor are amazing productive.
That said, Opa has a lot of competition. I am thinking of Clojure + Clojurescript, Meteor, Dart, etc. I don't much use Dart, but C+C and Meteor are amazing productive.
It looks like you put some serious work into this project but I do not really like the end result.. somehow it reminds me of 90's PHP code.
btw great docs, installation instructions and the landing page
How does Opa comapres with the scala lyft framework(which also promises a lot in the security area) ?
[deleted]
Is it still a compile to test environment?
Reading the different comments, I must say that Opa is still active (although we lack resources to animate the community). We are a small French startup meaning that I get to spend 50% of my time struggling with administration, and our evangelism resources are not compatible to those of companies like Meteor (and btw, Opa predates Meteor by a while).
Currently, we use Opa to build a secure communication application, named PEPS :
https://github.com/MLstate/PEPS
which is a good example of a "big" and open source application written in Opa. Note also that bringing a new language (or framework) from toy examples to real apps is definitely not easy.
Overall, quite glad to see that many things we introduced in Opa ("JSX" syntax, CPS-transforms, etc.) are becoming more prevalent, especially thanks to ES6. Indeed, adapting Opa to ES6, which we are looking at right now, would enable existing applications to use the latest ES6 features without changing the app code.
That was one of the goal of the project: Opa was meant to be a "good way" to write applications, letting the compiler choose a target platform and write code for it.
Opa is still relevant today, as a "good quality" (especially in terms of safety -- and if you are interested in certified applications like common criteria, please contact me: Opa is relevant in that space) "one-stop shop" to build develop web apps or services. Remind that when we started a few years ago, many were criticizing that we use a functional programming language, were telling us that nobody wants static typing, etc. (that was before Hack which helped a lot in popularizing the feature -- and Opa too is written in OCaml).
And Opa has a future. The way the compiler is written, it's not that hard to have it compile the same application code into cloud platforms, including a lot of Amazon Lambdas...