Show HN: Jolie – The First Programming Language for Microservices

by fmontesi • 11 years ago

64 36 11 years ago

harisamin• 11 years ago

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

thesave3• 11 years ago

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 [2] http://docs.jolie-lang.org

marktangotango• 11 years ago

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

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

rasur2• 11 years ago

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

thesave3• 11 years ago

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/

fmontesi11• 11 years ago

We are in the process of moving to github, but it is not a high priority right now and we have so many things to reconfigure in our servers that it is not going to happen until March at the earliest. Meanwhile you can use svn:

svn co svn://svn.code.sf.net/p/jolie/code/trunk jolie-src

You can also browse the code here:

https://sourceforge.net/p/jolie/code/HEAD/tree/

kaonashi• 11 years ago

How does this differ from say Erlang and OTP? (conceptually)

Licenser• 11 years ago

That is exactly what I wondered, sadly the page does not mention Erlang/OTP whatsoever.

fmontesi11• 11 years ago

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.

fmontesi11• 11 years ago

Another thing: the fact that it is imperative does not mean that we suffer from all the side effects. You cannot share data among different microservices, you must use communications (if you need performance, communications can be in-memory). The imperative paradigm (mixed with workflow programming) is used only for internal state manipulation, so that it is safer for concurrent programming.

I should really get down to write all of this in the FAQ page.. ;)

jlouis• 11 years ago

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.

alexchamberlain• 11 years ago

Shame its GPL'd.

thesave3• 11 years ago

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

fmontesi11• 11 years ago

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

zerr• 11 years ago

Code examples should be in public domain.

BradRuderman2• 11 years ago

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?

fmontesi11• 11 years ago

It may be the late hour here (CET), but I only kinda understood your question. What do you mean by "I can't replicate my model logic in my node services" ?

qooleot• 11 years ago

I think by "model logic" he is referring to MVC and things like data model relationships (and an ORM possibly), validation/casting, etc.

For example, in a single programming language and framework you could say:

payment.isPayPay()

from a payment out of a database wrapped into a model.

It has not been traditionally easy to share that business logic across languages (and by easy I mean not wrapping huge numbers of methods in http requests).

dragonwriter• 11 years ago

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?

e12e2• 11 years ago

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?

cguidi2• 11 years ago

I am not sure I understood well the question but I hope this answer could help you. Usually in Jolie we proceed as follows: - the logic (the one which should be replicated) is served by one microservice (which could be embedded or deployed separately, it doesn't matter). Let me call it L. - the other entities which requires that logic just invoke the microservice L - in the case of the web app, we use Leonardo (http://sourceforge.net/projects/leonardo/), which is a web server written in pure Jolie, we public the calls to L by simply adding them in few lines of code through aggregation. In this case Leonardo, which serves the http protocol, just take the message, transform it in another protocol (we usually exploit sodep for Jolie to Jolie communication) and redirect the message to L which exectues the logic.

e12e2• 11 years ago

So... the code[1] for Leonardo is certainly short and sweet -- but is this considered a production-grade web server? I doesn't appear to do anything in parallel (no "|" in the code, anyway) -- is this a thin wrapper around something more robust in the Jolie standard lib/run-time?

[1] http://sourceforge.net/p/leonardo/code/HEAD/tree/trunk/leona...

If not Leonardo -- is there some production-quality, yet simple, code that one could look at to get a feel for how an actual Jolie service might look? Say a micro-blogging site or something?

Always interesting to see new languages and platforms!

facepalm2• 11 years ago

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

ch4s3• 11 years ago

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

facepalm2• 11 years ago

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.

al2o3cr• 11 years ago

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.

cguidi2• 11 years ago

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

Show HN: Jolie – The First Programming Language for Microservices

Related Stories