Hacker News new | past | comments | ask | show | jobs | submit login
Jolie, the service-oriented programming language (jolie-lang.org)
116 points by todsacerdoti 27 days ago | hide | past | favorite | 58 comments



Looking at a Database example[0] doesn't make me want to write this more than using any other framework.

[0] https://docs.jolie-lang.org/v1.11.x/language-tools-and-stand...


Maybe it's just a bad example, it doesn't look much different than what I can do in C#.


Why would you showcase a bad example if there was a better one?


What I meant is, not every language is better at every problem. It's maybe a bad example to showcase Jolie's strengths.


Maybe we're just fish in water and don't know any different? GP, is there a better way?


has refinement types. these exist in fstar lang and liquidhaskell.

dependant types are not refinement [0]

ts and rust have ideas to have them[1], but not so officially

[0]https://www.reddit.com/r/dependent_types/comments/ay7d86/wha...

[1]https://en.m.wikipedia.org/wiki/Refinement_type


Also see WUFFS for a special purpose language which leans really hard on refinement to deliver safety with socks-blown-off performance in a specific niche.


I was kinda forced to use it for an university exam.

The premise was interesting but working with it was bad.

Maybe it improved in the last 5/6 years, but I doubt it's used for many (or any) real use case.


The vast majority of programming languages would be terrible for production code in a real business setting. We share and discuss them here not because we're looking for something to replace the big few languages at work but because the niche and obscure ones often explore very interesting ideas.


Kinda interesting that there seems to be a few similar ideas with https://serviceweaver.dev/

I'm guess eventually this will be the way but not for a while.


This sounds very much like COM. https://en.m.wikipedia.org/wiki/Component_Object_Model


I think it would be better if this was a code generator similar to `protoc` for gRPC, so we don't have to learn yet another implementation language.


One of the devs here. We plan to release an updated code generator (jolie2java) that will make it easy to do exactly that. (For Java, but Jolie is already designed to support other langs as well in the future.)

Specifically, you'll be able to use Jolie to write (tech-agnostic) APIs and then implement them in Java, using types automatically generated from the Jolie APIs.


This is good to hear - the big problem I have with justifying more niche languages is that I have to ultimately use some niche library at some point that only exists for more established languages.

I hope you guys try to make a first class transpiled language.


So it's like ballerina lang? (ballerina.io)


I looked it up because I was curious. Jolie stands for Java Orchestration Language Interpreter Engine.


Seems like a backronym to me.


For those who don't know, jolie means pretty in french, and is a common woman's name.


I don't think I've heard heard of someone named Jolie.

According to data from INSEE (France's Census Bureau equivalent), since 1925, only 6 babies were named Jolie in 2011 and then 5 more in 2018.

There's a Joline which you'd pronounce pretty much like jolie as the n is very weak, but it's barely more popular.

Anyway, jolie does mean pretty, but it's not really a name (11~0 at this scale).


I'm pretty sure you've heard of at least one person named Jolie: https://en.wikipedia.org/wiki/Angelina_Jolie - but of course she's not French, I guess her parents picked the name because it sounded nice, and she thought it sounded so nice that she picked it as her stage name...


I suppose the parent commenter mistook Jolie for Julie which is indeed a common French (and not only) name.


Her mother had French-Canadian roots.


Yeah, but that's a last name. I was talking about first names which is usually what people mean when they say a common name.

I'm guessing the other commenters are right, GP probably meant "Julie".


Angelina Jolie is a stage name. She was born Angelina Jolie Voight. Jolie is a middle name there.


Yeah Julie/juliette are common as a first name but do not share etymology (comes from julius).

A more common last name is Joly which is old form from joli, the masculine form of jolie.


It does mean pretty but it is not a common french name.


on the basis that there aren’t many kids named Pretty by their English speaker parents, surely it’s more likely that a non-French speaker would name their kid Jolie


I knew a woman whose last name was Jolie... Her parents named her Très ("très jolie" means very pretty).


> The basic building blocks of software are not objects or functions, but rather services that can be relocated and replicated as needed.

No? Most software I use is a single service (in a sense that it's compiled to a single executable).


I assume this language is named after Jolie in Avatar The Last Airbender? (https://avatar.fandom.com/wiki/Zhu_Li_Moon - the pronunciation is the same)


Jolie stands for 'pretty/beautiful/attractive' in feminine form in french and is sometimes used as a noon when mentioning a person more often in a condescending manner.


Whenever Jolie is posted in a forum, the same discussion about its name is recreated.

It is, however, the first time that I see the 'airbender explanation'. Nicely done!


Zhu Li eyes are curvy at the top and straight at the bottom (see the image), while the Jolie eye is the exact upside down of it.


This looks like Mule ESB 1/2.x configuration sans the XML


Was curious at first but got more disappointed the further I read.

The docs are overly wordy and in desperate need of editing.

It claims it's a language, but it looks more like a DSL on top of Java with non-obvious syntax.

It's been around since 2014? Is it used for anything serious? Or just riding the microservices gravy train?


It is used in industry, yes, but is still quite niche. For example I know of journalism tools at media companies, document systems, websites, and a payroll system. It's definitely used as a stable platform in a few places but could use more libraries (things are getting active there though, plus you can reuse anything from the Java world).

The docs really need some love.. : - )


A lot of this looks similar to what GraphQL with something like Apollo Federation gives you:

1. A contract-first language where all of your queries (reads) and mutations (writes) are defined in the GraphQL type language.

2. Refinement types can be implemented with directives or custom scalars.

3. The "built for the networked age" section is very similar to what Apollo Federation gives you - the ability to move implementations of part of your GraphQL API service to different servers with end clients being unaware.

4. Protocol agnositic - technically GraphQL is protocol agnostic but in really nobody cares because everyone uses HTTP or Websockets.


Definitely worth a look.


I can't see past the gigantic tabs


  email:string( regex(".*@.*\\..*") )
This is incorrect regex for email. The correct one is https://pdw.ex-parrot.com/Mail-RFC822-Address.html


It's a pragmatic one. It has no false negatives, and there's rarely a reason to care about false positives. (Especially not where a stricter regex would (be the only mechanism to) catch it, but a fake-but-valid address wouldn't trivially bypass it.)


At the very least, I assume .+ at the start is a better choice.

The RFC says:

     addr-spec   =  local-part "@" domain        ; global address
     atom        =  1*<any CHAR except specials, SPACE and CTLs>
     word        =  atom / quoted-string
so I think the bit in front of the @ has to be non-empty.


Yeah, I agree, I think I'd have written that myself, but I don't think I'd reject it in review on that basis. I don't agree with sibling comment that it's 'shitty', it's trivially improved sure but it basically doesn't matter - if you want it to be actually correct you need to send an email to it for verification anyway.

Otherwise we can start saying not just not empty, it also needs no other @s etc. and before you know it we're rivalling the actually correct attempt up-thread. If you just want to catch typos, encourage entering real address (not just a space or full stop to fill mandatory field) then any basic thing is something, a compromise between legibility and how much it'll catch, we know there's a tonne of (mainly adversarial) bad input it'll miss, that's fine.


Agreed. I should have said so, too.


I agree with the sentiment, but this one is just shitty. Switch out the stars for pluses and it’d be a lot better


At a certain point I think you're allowed to say you don't care if the person with this email address is capable of signing up or using your service:

very.”(),:;<>[]”.VERY.”very@\\ "very”.unusual@strange.example.com


Too bad - if that's my email address and you're rejecting it, I'm going to sue you for denying service arbitrarily and win. Not every country is the USA.


> I'm going to sue you for denying service arbitrarily and win

Which country are you claiming this entirely implausible legal scenario would work in?


The denial of service was not intentional so I doubt you would win anything.


You'd have to fix your code, at least.


Is there a country where this has happened?


There is a typo on line 17.


That is an absurdly complex regex


Email address specs turn out to be rather complicated.

I really wish people wouldn't code their own checks rather than use already existing standards. Some languages like Java even include proper checks in their standard library: https://java.net/projects/javamail

Several jobs back I had no end of arguments with some Java devs about not writing their own checks, that kept routinely failing on legitimate addresses.


But why do you even need to validate that email? Send the subscriber a confirmation link - if they get it then it was valid, if not then it's on them to fix the situation in whatever way they find fit.


A single massive and unreadable regex isn't an appropriate way to validate a spec that complex. With its complexity it can't be logically evaluated- only tested, whereas a function that breaks the spec out into steps/parts is going to be a lot more maintainable, readable, and auditable.


It's all devs in general. As a java dev I have lost count of the number of times I have to tell any dev not to use a damn regex to validate emails.


It really is, I wonder if anyone has tested that extensively. It's so complex that just by reading it I don't think anyone would be able to confirm it matches the RFC correctly.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: