From the homepage:
Thinking in services
Jolie crystallises the programming concepts of service-oriented computing as linguistic constructs. The basic building blocks of software are not objects or functions, but rather services that can be relocated and replicated as needed. A composition of services is a service.
Tailored for microservices and APIs
Jolie is a contract-first programming language, which puts API design at the forefront. It supports both synchronous and asynchronous communication. Data models are defined by types that support refinement […], and DTO (Data Transfer Objects) transformations are transparently managed by the interpreter.
From vision:
Our vision is to design a programming language with a different trade-off: instead of optimising for computation, the aim of Jolie is to offer native abstractions for the creation and composition of services.
By shifting the focus on services from libraries and frameworks to the programming language, we can change significantly how programmers manage their knowledge regarding service programming. The key idea is that the important abstractions for service programming should be crystallised in the programming language, translating to an easier learning curve for new service developers and less knowledge to be managed.
That’s a cool idea, though obviously you need functions and objects to actually make services do useful stuff. And lots of libraries. I achieve most of what they describe quite easily using GRPC/protobufs with Go, and so I have doubts that this is going to be better. Plus GRPC/protobufs have the benefit of working seamlessly with other languages, and with some small added code, you can add annotations that handle auth, routing, validation, etc
Service-oriented architecture does not imply SaaS.
Obviously plenty of FOSS software uses servers. IRC, Mastodon, Email, NTP, X11… There are plenty of good uses for service-oriented architecture in FOSS.
