Hacker News Reader

Comment by danellis | Hacker News Reader

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.

View on HN

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/

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.

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

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.

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.

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.

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.

Reply on news.ycombinator.com