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.
