Jolie, the service-oriented programming language | Hacker News Reader

Jolie, the service-oriented programming language

jolie-lang.org

171 pointsRcrdBrt75 comments

Who actually wants this? People want good libraries for doing this with the languages they already use, not to have to make compromises just so they can have a microservice. Notice that the front page gives lots of examples of the servicey parts of the code, but absolutely no examples of what the business logic looks like. In fact, even in the documentation, the example code is minimal and trivial.

I want it. There are people who don’t mind learning a new language if that’s the trade off for having to write services by hand, especially if the language isn’t so drastically different from what they already know.

Looking at the stakeholders section at the bottom, this looks like the typical academia project that is, currently at least, far removed from the real world.

That's exactly my first thought.

But: I'm currently working on a distributed Webassembly runtime. Jolie seems like a great way to describe your whole system.

For each service the executed code would be a function exported by a Wasm module, written in the language of your choice.

Distrubted wasm runtime sounds interesting. Would you mind sharing a link to it? :)

Not ready yet. I hope to open source it within the next few months. Will submit SHOW HN post then.

It seems like the approach which should really be taken instead is allowing the importing and/or definition of biz/pattern-specific DSLs.

I don't think there's really any way to make a language with this stuff entirely built-in (rather than providing a general DSL feature) which is both flexible and terse

I want it. At least the idea of it.

I want something that looks like a programing language ( the mainstream ones ) that describes and specifies the flow of some functionality, not a YAML or a godforsaken XML file but also not XYZ framework that has all the implementation details.

Maybe Jolie isn't what I want and has more baggage than I'm currently aware, but it somehow looks like something I need.

Could you achieve that with a language that has a sufficiently decent meta-programming option, like a macro system? It sounds like what you want is a compile time validated state machine.

Writing a language from scratch is not that different from writing a DSL using powerful macro systems. Does such a DSL already exist?

It depends on what you're looking for. Based on my usage of Rust, I would say that it's proc_macro system is more than capable enough for use-cases like this, and macro_rules migth even be enough.

But lots of languages offer similar capabilities, Nim, Racket, Scala, Julia, Lisp, etc.

in C++ it's simple enough that you can build one accidentally https://philippegroarke.com/posts/2020/constexpr_fsm/ :p

Is it just a matter of procedurally generating config files? Would that satisfy you?

Would Dhall [0] suffice?

[0]: https://dhall-lang.org/

It gets my interest for being contract first.

I want it.

You could argue that the current approach of intrastructure-as-code has it backwards:

Currently, you define infrastructure, then deploy your code.

Instead, I'd like to be able to write code and then connect the code through infrastructure abstractions.

Indeed, one of the nicest aspects of Jolie is that you can (semi-)automatically extract the definition of the infrastructure that you need from your code.

An example of a preliminary application that you might find interesting: https://arxiv.org/abs/2103.09518

You may find this link helpful https://dzone.com/articles/introduction-to-jolie

Agreed.

It's a lot easier for full blown languages to offer servicey-like interfaces like Jolie than the other way around.

And as a matter of fact, most modern programming languages offer interfaces/traits/stubs/etc... that do just that.

A great example of a successful approach to this is Retrofit: https://square.github.io/retrofit/

I don’t know about specifically this, but I’m excited for languages that are built from the ground up for distributed computing. Distributed computing is already hard, but I feel like out general toolsets make it harder than it needs to be.

> Who actually wants this? People want good libraries for doing this with the languages they already use

Like the JVM? This runs on JVM.

I also noticed that information about the actual logic part of the language seems sparse, and would offer that as feedback for the author(s), but the last thing HN needs is more people being haughty and dismissive until an absolutely rock-solid case is made for immediate utility. Isn't it enough to be curious about the ideas represented here?

I think it may get popular for Java framework fans. Among themselves folks may bicker about J2EE, Spring or Quarkus, or Oracle Fusion, Microprofile and myriad others. But the core idea is that anyone using Java directly with some help of standard and third party libs is old fossil and should eliminated from project/company or even better from workforce entirely.

I think this language is another form of framework and unsurprisingly developed in Java for java users.

The interpreter has been developed in Java but, from a linguistic perspective, Jolie is completely independent from it. It is possible to implement the interpreter using another technology. Thus, it is wrong to state that it is another Java framework, but it is true that, by now, it is coupled with Java because you need a JVM for running it.

Woah, so this happened. Maintainer here. I'll do my best to reply to all questions/doubts that get posted about an hour from now, since there is some valid feedback and there are some good questions in here.

I think the predominant question here is: why a language over, eg., a framework?

https://dzone.com/articles/the-red-pill-of-microservices

In a nutshell: because we want to minimise code <-> model distance. Other languages make you program in terms of functions, objects, etc., and make yourself model services by using these concepts. In Jolie, you write code that maps directly to the concepts that matter. What are the important concepts? APIs, Access Points, and Services (duh..) are examples.

Some more info at:

- https://dzone.com/articles/introduction-to-jolie (a brief introduction to Jolie and some concepts)

- https://hackernoon.com/a-detailed-introduction-to-service-or... (a deeper dive/discussion on some of the concepts)

Our (for now subjective) experience is that people who become familiar with Jolie are much faster at prototyping a service system, which makes it worth pursuing for us. Jolie code requires less boilerplate and state management for interesting scenarios. Two examples: communications can be natively composed in structures, e.g., the code

  open()
  close()

mandates that only the open operation is available at first and then only close is available (in object-oriented languages, you must encode this state with a private data field and manage it with if-then-else, etc.); likewise, streams in Jolie are consumed by writing

  provide
    [next(element)] { ..manage element here.. }
  until
    [end()] // stream ended here

which means "provide the operation next to invokers until operation end is called". A syntactically manifest approach to reactive programming and state machines, if you like.

Another big reason for exploring languages is discipline. Languages discipline how you write code. An example: in Jolie, you decompose software in terms of services. Many of these run locally as libraries, and are optimised by the interpreter by using hidden shared memory. But the language enforces that if you ever decide that a component should become an external, independent services, you can do it by updating a few references (input/output ports, our access points). See also https://fmontesi.github.io/2015/06/09/non-distributed-micros... Another example: Jolie discipline also gives you the ability of reusing the same business logic under multiple access points with different protocols.

This is the tip of the iceberg. In general, programming in terms of service abstractions is showing to be an interesting experience for us.

Phew, that was quite a bit for a "in a nutshell".. I hope that it's clear, otherwise, just write below.

Could you expand on this? I'm not seeing why the "duh" is warranted.

> Jolie, you write code that maps directly to the concepts that matter. What are the important concepts? APIs, Access Points, and Services (duh..) are examples.

I come out of the Domain Driven Design school of thought, where the true key concepts are the domain-related ones. E.g., if you're doing ecommerce, things like Product and Order are much more important. They're also much more stable. Over time what gets exposed as an API will vary much more than whether or not we have a Product or an Order.

What you're calling important is what I think of as implementation details. Important in the sense that pipe fittings are important to a house: vital, but very much secondary to the purpose.

I was indeed talking about implementation models, in particular models of service-oriented systems. These are usually formulated in terms of services, DTOs, APIs, business logic, etc., hence the value brought by Jolie in giving a direct syntactic representation. The model of an implementation can change often, so it's important to have code that resembles it closely (for readability, editing, etc.).

You're talking about the domain model, which I agree is more abstract and stable. It comes before making the implementation model. In the case of microservices, some concepts overlap and/or are very similar between domain and implementation, but some mapping is required. We started exploring a bit how to relate MDE languages to Jolie in https://arxiv.org/abs/2104.02458 and it looks pretty promising in the sense that they seem easily linkable.

In short: once you get to the implementation model and if this is service-oriented, Jolie gives you a concise and executable syntax to write it. (And there is ongoing work on how some elements of domain models can be mapped automatically to Jolie concepts.)

Thanks for the explanation.

I'd say that you idea of Domaim is unduly restrictive. Yes, in an e-commerce or a merchandise based business, Products and Orders are domain objects. But services and ports and interfaces are every bit as real from a complementary domain - the domain Of software design and Technology Operations.

We are at historically bad levels of Interoperability because we don't really engineer software for management. We just call it an implementation detail.

Domains overlap. An e-commerce system will have a domain perspective to Infrastructure and the Infrastructure provider will have domain perspective on a Tennant like a specific e-commerce system. Bother are valid. There's real value in reducing the impedance between those views

It's true both are valid, but I think you miss that the domain of software design and technical operations is a) secondary to and dependent on the actual business, and b) far less stable than the domain. As somebody who has written software and done ops for decades, I certainly value it. But I think it's a mistake to put it on an equal footing with the actual purpose of the enterprise.

How's the performance? How many concurrent requests can it do? Is it reliable and production tested?

Wow. This looks really promising. I always found it a bit awkward that you have to bend the other languages to fit in the microservices model. I mean, yes, it's easy to do so in some of them but still there always seems to be a lot of boilerplate that you have to reiterate again and again. I think it was about time to have a language that takes care of the basics. Another one that I had in mind was ballerina (https://ballerina.io/) but unsure how it actually fares so far.

Interested to hear production or even PoC stories on both of them.

Thanks for sharing.

I think I can answer to this one, Jolie has been so far in implementattion of microSOA in medium size enterprises; In the company where I currently work we use Jolie to develope the backend part of a web product. If you are interested you can join us in the discord channel https://discord.com/invite/yQRTMNX I will be happy to share my experiences

Super interesting! We're doing something similar with Encore [1], but instead of building a whole new language we let you program using Go. Looking forward to see where this goes :)

[1] https://github.com/encoredev/encore

Cool project, I'll check it out.

The JVM ecosystem is fairly amazing. I don't write much Java code anymore, but Clojure on the JVM is practical and modern, good for some of my projects.

I was looking at the Jolie (Java) source code and noticed a GNU license in some source code, but a top level Apache language - if I understand that correctly then that should be fixed.

Anyway, interesting project.

Slight tangent, but I much preferred the trend of language names being letters, gemstones, animals or coffee related, and something about programming languages names being commonly used woman names makes me uneasy. I don't know why, there's some sort of uncanny valley about it, some kind of scifi-esque AI-love cringe to it reminding me of the movie Her and the likes. I'm not dismissing the technical merits, and Julie sounds interesting, and I'm quite fond of Julia and Janet langs, but I've noticed this name trend and there's something interesting about this meta-social trend of using woman names for them.

The project maintainer has stated below that it's "jolie" (French for "pretty"), not Jolie the actress.

I'm a french speaker, Jolie is a common woman name, yes it also means pretty, but that's like people called Lily or Prince. The logo is also a woman's eye + brow.

It's possible the author was going for the meaning of pretty, but there still seem to be a strong personification happening with emphasis on it being a beautiful woman, and it's that aspect that unease me.

Again, you can call your language however you choose too, and I'm not going to judge it by its name, but I still personally find this womanization trend in programming language names a bit weird.

I'll probably get used to it, though it does feel like an interesting meta-psycholigical subject as well. Where are the programming languages named John, Richard and David? Why are we calling a language by a person's name? Why are their logo becoming human facial features?

Intra-male competition

Telling that Jenkins is a servant

> Jolie is a common woman name

Where? It's not even on the INSEE tool https://www.insee.fr/fr/statistiques/3532172, according to their "Fichier des prénoms" (https://www.insee.fr/fr/statistiques/2540004), there are currently 39 persons named "Jolie" in France. This is not to dismiss the rest of what you said, I'm just curious as to where "Jolie" is a common woman name.

Well, I had never really researched this, but I'm from Quebec, and I know 3 Jolie. Maybe it's more prevalent there, or maybe I happen to know a coincidentally large number of them. If the latter, I guess that is a good learning experience for how your own life experience can easily bias you in your opinions and understanding of some things.

I was curious about this so I searched around a bit and found the data for girls names from 1980 to 2020 [1]. I've found 269 people with first name containing "Jolie". Then I took the census data [1], found that 45% of Quebec females are under 40. So extrapolating from the first number, I find 524 females with Jolie in their names in Quebec.

That means 1 in 7915 female in Quebec has Jolie in her name, compared to around 1 in 1 million for France. That explains (in part) how you know 3 and I don't know any I think.

[1]: https://www.donneesquebec.ca/recherche/dataset/banque-de-pre...

[2]: https://www12.statcan.gc.ca/census-recensement/2016/dp-pd/pr...

Interesting, thanks for looking it up. I quite like the name personally, though it still seems I have some chance in my sample, since I do not know 7915 woman, so to know 3 Jolie still seems a little lucky.

Not that any of that really applies here: "Jolie" isn't[1] a woman's name. Maybe you're thinking of actress Angelina Jolie, whose surname it is? As such, it can apply just as much to men.

Also, in French it's a regular adjective that means ~"cute".

___

[1] EDIT: Except, according to comments close by, in Quebec.

The paradigm reminds me of the message passing paradigm in "early days" object oriented programming languages such as Smalltalk. I guess remote procedure calling (RPC) and message brokers (COM and friends) is the 90s or 2000s version of distributing these messages (network transparency). How does Jolie relate to these concepts?

I just wonder, when looking at enterprise Java, whether there are not mature libraries which allow for distributed and high level application writing without changing the whole software ecosystem.

With all due respect but why not changing the software ecosystem? Is enterprise Java the pinnacle of SW engineering? Last time I checked it seemed to me that it's share is being eaten away slowly but steadily from Golang which is deemed to be a far better option for modern cloud-based enterprise apps. Not to mention the significantly better (aka simpler) programming model with all the benefits that it brings. Also, younger devs are shying away from the language and the platform -and this is far deeper than just a generational thing.

So to me, if I were invested in JVM (I'm not), a language that looks to bridge JVM with microservices/cloud would be great news. But instead I only see pushback from Java community. And this is not the first time I see it as well. Same exact behavior to functional efforts such as Scala or anything functional really. A kind of "we're fine we don't need anything new" which I cannot understand.

Starting with Java 8, Java has been adopting functional programming ideas, and appears to be heavily influenced by Scala.

I'm talking about the initial reception Scala had from a lot of people in Java community. Btw downvotes further confirm my views of them as being overly conservative and hostile to different views.

The vision and model here seem excellent. Jolie as a language seems to have strong roots in academia and Europe. The one alarm is the lack of information on real world use, case studies and non-trivial adopters or users.

Anyone know of any large scale use of Jolie?

IIRC, in industry, there is at least one big system with 50-ish microservices that includes electronic invoices. (See https://www.conf-micro.services/2019/papers/Microservices_20...)

At our place, we have a few websites written in Jolie and a system of services for evaluating software projects (for exams).

Feel free to drop in our chat if you're interested in chatting more about this with others as well: https://discord.gg/yQRTMNX

I absolutely adore this. Thanks for sharing it!

Thanks for the kind words, I'll share them with the rest of the team.

I think a framework on an existing language would be a much choice instead of learning a totally new language just for this.

I'm very happy to see SOAP supported.... Well no, not happy, but... It's expected in many of the areas where I work.

It's nice to see that I can easily create a SOAP webservice, without Java or .Net, but that there's anything wrong with those two languages.

Yeah, we have SOAP because... SOAP (just because of interoperability).

Our SOAP is quite palatable at least, because of reduced boilerplate. AFAIK Jolie devs don't typically use it (I don't at least), unless it's really necessary (interoperability with legacy web services, business requirements, etc.).

if anyone has been wondering: "SODEP (Simple Operation Data Exchange Protocol) is a binary protocol created and developed for Jolie".

So far i didn't find any indication that Jolie supports grpc; I think that it would be very helpful if the developers decide to support grpc as well.

https://docs.jolie-lang.org/v1.10.x/language-tools-and-stand...

Jolie and SODEP predate grpc, so we don't have grpc just because we had no need for it (we already had a binary protocol with expressive interfaces).

It's definitely something we'll get around doing sooner or later though, since so many people use it, and we do care about interoperability. Contributions towards this would certainly be welcomed warmly.

PS: We support integration with Java, so you hack your way around this by using some Java code for grpc, but it doesn't feel "native" and require some boilerplate.

Reflow [1] is a similar attempt at a slightly different domain: bioinformatics and ETL pipelines. Reflow exposes a data model and programming model that reclaims programmability in these systems, and, by leaning on these abstractions, gives the runtime much more leeway to do interesting things. It unties the hands of the implementer.

[1] https://github.com/grailbio/reflow

Its cool that someone wrote this, but practically, this sounds like it encourages to microservice hell with many unnecessary services. A service should not be written to enforce separation of concerns. We have classes and functions for that.

In jolie, develoeprs program services instead of classes or functions. I think this is the main novelty introduced by jolie. Everything is a service, and you can postpone the decision on how to deploy an application. You can deploy it as a monolith (so your services will play the roles of classes, because they are internal) or independent services.

thanks for the reply. My concern was people writing services that available on the network for trivial use cases, where a class or function would be faster and as reusable. You have addressed that concern. In light of your answer, is Jolie similar to an actor based pattern like Akka, with services being the abstraction rather than actors?

I am not an expert of Akka, but more or less the answer could be yes. I don't know if the following features are supported also in Akka:

- In jolie, it is quite transparent to develop a monolith or a distributed system of services. You always develop services and finally you can decide if deploy them as a monolith, or fragmenting the deployment into a distributed solutions (https://dzone.com/articles/between-monoliths-and-microservic...)

- Any input endpoint of Jolie (named inputPorts) can be exposed with different protocols (http/json, http/soap, sodep, etc) and you can have more inputPorts at the same time, thus you can receive messages for the same business logic from http/json, http/soap, etc. You can also split the available operations in different inputPorts. As an example you could receive admin messages in a https port, whereas you can leave in http teh public ones. But you can build meven more complex scenarios thanks to this feature.

I think it's akin to the original conception of OOP in Smalltalk, where objects are passed messages. (I've never written ObjectiveC, but I believe that's its paradigm as well.) In that, it's similar to the actor model used in Akka and in Erlang.

If you think of a service as being like a class -- as originally conceived by Smalltalk -- then sending it messages and acting on responses is the very definition of OOP, at least according to Alan Kay, the inventor of Smalltalk and of the term "object oriented programming."

There's an interesting discussion of the definition of OOP here. https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

Interesting; i will give it that.

But i'm kind of stuck in programming sockets in C till i die

Haven't looked at Jolie closely, but I am very well-versed in gRPC. Can someone give a quick comparison between the two or point me to a good resource that compares the advantages of Jolie over gRPC or vice-versa?

Now the only language missing is Varic...

I might be misunderstanding the use case but does this support azure or AWS or just its own server?

Sure does. Jolie applications can be containerised like any other.

See here for Docker and Kubernetes: https://docs.jolie-lang.org/v1.10.x/language-tools-and-stand...

It's also been tested with Azure Functions (serverless): https://mmontesi.blogspot.com/2020/06/jolie-on-azure-functio...

I wait for the language Angelina, Veronica, Mrs. Smith etc. Smart dream you can say.

It's Jolie as in pretty, not as in Angelina.

But I don't wanna stop you from making all these languages... (o:

Reply on news.ycombinator.com