
Show HN: Jolie – The First Programming Language for Microservices - fmontesi
http://www.jolie-lang.org/
======
kaonashi
How does this differ from say Erlang and OTP? (conceptually)

~~~
fmontesi
Right, excellent question. We should put something in the FAQ. It's going to
take some time to answer properly, but here are some initial pointers. Note
that while I know Erlang academically I am definitely not an expert, so feel
free to add more comments if you like.

Both languages are based on message passing, but Erlang is functional whereas
Jolie is classical imperative/stateful.

Jolie provides architectural programming, e.g., you can make proxies
abstracting from the behaviour of what you are composing with a language
primitive.

Jolie provides integration natively, e.g., with automatic data transformations
between different data protocols. The contract with the developer is that if
you need to change protocols or deployment information (e.g., switch from
TCP/IP to Bluetooth L2CAP or in-memory communication), you just have to change
a couple of lines in the deployment part of a Jolie program and the rest will
continue working without modifications to the program logic (logic/deployment
decoupling).

Jolie has dynamic fault handling: fault handlers can be updated at runtime
compositionally (higher-order code composition), which is afaik a new thing.

~~~
jlouis
None of those concepts seem unique to Jolie compared to Erlang, but I have yet
to understand the concepts of Jolie well enough to figure out if something is
conceptually different.

Architectural programming: gen_server is a fine example.

Integration: Erlang is opinionated but as soon as you have a lens to erlang
terms, everything is easy. This is the point where Jolie may have an
advantage.

Dynamic fault handling is subsumed by dynamic code loading.

~~~
fmontesi
I would be very interested in seeing a comparison with gen_server, it looks
interesting.

Embedding in Jolie looks like a language primitive implementing something that
resembles some of the ideas found in supervision trees.

AFAIK, dynamic fault handling is not subsumed by dynamic code loading in the
specific case of request-response operations in parallel code
([http://iospress.metapress.com/content/p0647559l8455778/?issu...](http://iospress.metapress.com/content/p0647559l8455778/?issue=1&genre=article&spage=73&issn=0169-2968&volume=95),
see my webpage fabriziomontesi.com/research.html for the pdf), but if that's
relevant for the comparison with Erlang, I don't know. In all other cases your
statement is correct. It's subsumed also in that case if you allow for dynamic
code loading in the middle of waiting for a response for a request in a
request-response invocation.

Another point which may be interesting: in Jolie a process inside of a
microservice can have many input queues. Which messages go in which queue is
decided by (an easier form of) correlation sets, basically a declarative part
of the program where the programmer tells which parts of messages identify the
queue in which they must go. These can be application data or even HTTP
cookies, we use this features a lot for integration.

~~~
fmontesi
It looks like another interesting difference may come from the workflow
primitives (e.g., sequence, parallel, input choice) that Jolie comes with.

------
BradRuderman
In my experience the biggest frustration when building microservices is the
replicated logic across multiple languages/frameworks. For example if my
microservices are in node/io.js and my app a rails app, then I can't replicate
my model logic in my node services. Have you done anything in the jolie
language to help this problem?

~~~
dragonwriter
> For example if my microservices are in node/io.js and my app a rails app,
> then I can't replicate my model logic in my node services.

Why would you want to do this? If something is the responsibility of one
service, why is another service or app duplicating its logic?

~~~
e12e
Perhaps several layers of input data validation? Typically the problem is that
you want the client side (ie: javascript) to do form validation for early-
feedback to the user, and the back-end to do actual input filtering/validation
-- but I suppose one might want to push input-errors/validation-errors as far
out towards the input as possible -- also in case of a web of micro-services?
Things like allowing only utf8, or maintaining data integrity for
relationships (eg: in order to add dependants to a person, those need to be
defined with some kind of minimal data, like a social security number?).

I am a bit puzzled as well -- I normally think of this as a problem of
synchronizing back-end and front-end -- but then again, if you have a proper
SQL-schema, with a thin REST-layer abstraction/API on top, you'd probably have
to have other services know about your models in order to do input-validation
before attempting to post/insert/update data?

~~~
fmontesi
What we can do right now is having a microservice for input validation and
call it when we need to validate something, both from the client and the
server parts. In Jolie, adding calls to a validator for all functionalities
exposed by a microservice is easy with courier constructs ([http://docs.jolie-
lang.org/#!documentation/architectural_com...](http://docs.jolie-
lang.org/#!documentation/architectural_composition/couriers.html)).

However, if your client application is a web app, that may mean generating a
lot of traffic between clients and web server.

In theory, we could make a tool for automatically propagating validation
checking from Jolie to client code, but that's a hard problem because some
checks depend on information that only the server knows, so sometimes you need
to make remote calls anyway. Not all hope is lost, because in many cases a
static analysis could tell us what can be safely exported to the client and
what cannot.

------
al2o3cr
Looks interesting, but "It is used in Computer Science research and teaching
at many universities around the world." turns into "It's had papers about it
published by the same handful of researchers for the last decade" when you
actually look at the references.

Consider toning down the sales pitch and focusing on the language.

~~~
cguidi
We are in the middle, you know :-) Usually the academic part ask to us to
focus more on the research topics instead of the language details (they
usually call them "details" :-)).

We believe both of the aspects are very important. There are formal models
behind the language which are, and will be, very useful for building analysis
and verification tools

------
marktangotango
For anyone who is interested, the implementation is as an interpreter and
runtime implemented in Java[1].

[1]
[http://sourceforge.net/projects/jolie/](http://sourceforge.net/projects/jolie/)

~~~
rasur
Is there a git repo anywhere, out of curiousity? (Perhaps I'm being blind?)
This looks interesting..

~~~
thesave
Like marktangotango wrote, the official repository is at [1]

May I ask why you prefer git? For cloning/forking the project?

[1]
[http://sourceforge.net/projects/jolie/](http://sourceforge.net/projects/jolie/)

~~~
rasur
> May I ask why you prefer git? For cloning/forking the project?

Not that it's difficult to break out of the cycle, and download a tarfile and
so on but.. Yeah, creature of habit... git's part of the workflow these days.

(for better or worse!)

------
harisamin
wow really well done, now need some code samples in definitely languages to
illustrate this :)

~~~
thesave
I recently posted here[1] a tutorial on how to implement quicksort as a
service in Jolie. I think it could be a good starting point to learn some of
the main features of the language.

You can find a good deal of examples also in the official documentation [2].

[1]
[https://news.ycombinator.com/submitted?id=thesave](https://news.ycombinator.com/submitted?id=thesave)
[2] [http://docs.jolie-lang.org](http://docs.jolie-lang.org)

------
facepalm
I stopped reading when I saw the word "SOAP".

~~~
ch4s3
Why? Most modern tools are pretty good at Json, but SOAP is still everywhere,
especially health care. And, current support for SOAP in modern tools could be
better (outside of.Net land).

~~~
facepalm
OK, from that perspective it makes sense - if there are some APIs you just
can't go without. I just don't want to touch SOAP ever again, not even with a
10 foot pole. But maybe if this makes SOAP invisible it could be acceptable -
although I don't see how that could be possible.

~~~
fmontesi
Short answer: we usually don't use SOAP unless it is strictly necessary in
your system. We have simpler and/or more efficient protocols.

Long answer:

We do not use SOAP when it is not strictly necessary. Most Jolie programs use
SODEP (our own open binary protocol) or HTTP/JSON or HTTP/XML. You do not need
to deal with this manually, you just tell Jolie "use HTTP" or "use SODEP" in
the deployment part. For example, this is how you expose your service in
SODEP:

inputPort MyService { Location: "socket://localhost:80" Protocol: sodep
Interfaces: MyIface }

and this is how you get the same thing but in HTTP:

inputPort MyService { Location: "socket://localhost:80" Protocol: http
Interfaces: MyIface }

If you use Jolie to provide a SOAP service, it will most probably be
completely invisible. You just have to choose soap and you are done:

inputPort MyService { Location: "socket://localhost:80" Protocol: soap
Interfaces: MyIface }

Jolie will take care of using the right data formats without you noticing.

If you need to access an external SOAP service, there are many cases in which
it can be invisible, but also many other cases in which you will have to tell
Jolie some extra parameters in case some extensions or weird details need to
be used.

------
alexchamberlain
Shame its GPL'd.

~~~
thesave
The website is published under creative commons and GPL (code examples) but
the Jolie codebase is published under LGPL.

~~~
fmontesi
Maybe this is a good hint that we should clarify this in the footer. :)

~~~
mempko
Do not mind the other guy. Thank you for making it GPL'd. As a potential user,
I thank you.

