
The Opa Language - weavie
http://opalang.org/
======
hbbio
Project creator here (and kind of surprised to see Opa as news).

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](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...

~~~
nickpsecurity
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.

~~~
hbbio
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...](https://www.scribd.com/doc/271277920/Opa-BSL-Bypass-
Standard-Library)

~~~
nickpsecurity
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.

------
JasonSage
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?

~~~
acheron
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.

------
bishop_mandible
Every German speaker will read this as "The Grandpa Language".

~~~
KMag
"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.

~~~
curiousjorge
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.

------
thomasfoster96
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.

~~~
klibertp
> 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.

~~~
thomasfoster96
> 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.

------
inglor
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 :)

~~~
igravious
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?

~~~
klibertp
> 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](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.

~~~
marcus_holmes
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.

~~~
klibertp
> 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.

~~~
woah
Did erlang somehow make it easier to learn the additional languages?

~~~
klibertp
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 :)

------
inglor
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](https://github.com/MLstate/opalang/wiki/A-tour-of-Opa)

------
skeuomorf
People interested in secure web development frameworks should definitely check
out Ur/Web
[http://www.impredicative.com/ur/](http://www.impredicative.com/ur/)

------
dvt
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>
    

... especially when everything is moving into an MVC direction. I like keeping
my logic separate from my template. I may be too hasty. I'll definitely
download and check it out in more detail sometime this weekend.

~~~
klibertp
> 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._...](http://docs.racket-lang.org/web-
server/servlet.html#%28def._%28%28lib._web-
server%2Fservlet%2Fweb..rkt%29._send%2Fsuspend%29%29) (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.

------
mark_l_watson
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.

------
mhaberl
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

------
minthd
How does Opa comapres with the scala lyft framework(which also promises a lot
in the security area) ?

------
leke
Is it still a compile to test environment?

