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 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.
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.
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.
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.
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?
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 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.
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.
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.
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.
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.)
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.
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.
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 :)
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.
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.
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?
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.
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.
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.
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.
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.
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 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."
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.
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?
