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.

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.

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.

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.

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

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

Like the JVM? This runs on JVM.

It gets my interest for being contract first.

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

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

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.

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.

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.

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

Cool project, I'll check it out.

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

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.

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.

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

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

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

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.

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.

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

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

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

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.