7 ms·
Show HN: Jolie – The First Programming Language for Microservices
- carbonem 12y agoup
- readme 12y agoYou're gonna kill your new account. Don't post stuff like this people will down vote it and you'll be hell banned.
- harisamin 12y agowow really well done, now need some code samples in definitely languages to illustrate this :)
- thesave 12y agoI recently posted here[1] a tutorial on how to implement quicksort as a service in Jolie. I think it could be a good starting point to learn some of the main features of the language. You can find a good deal of examples also in the official documentation [2]. [1] https://news.ycombinator.com/submitted?id=thesave https://news.ycombinator.com/submitted?id=thesave [2] http://docs.jolie-lang.org http://docs.jolie-lang.org
- marktangotango 12y agoFor anyone who is interested, the implementation is as an interpreter and runtime implemented in Java[1]. [1] http://sourceforge.net/projects/jolie/ http://sourceforge.net/projects/jolie/
- rasur 12y agoIs there a git repo anywhere, out of curiousity? (Perhaps I'm being blind?) This looks interesting..
- thesave 12y agoLike marktangotango wrote, the official repository is at [1] May I ask why you prefer git? For cloning/forking the project? [1] http://sourceforge.net/projects/jolie/ http://sourceforge.net/projects/jolie/
- rasur 12y ago> May I ask why you prefer git? For cloning/forking the project? Not that it's difficult to break out of the cycle, and download a tarfile and so on but.. Yeah, creature of habit... git's part of the workflow these days. (for better or worse!)
- fmontesi 12y agoWe are in the process of moving to github, but it is not a high priority right now and we have so many things to reconfigure in our servers that it is not going to happen until March at the earliest. Meanwhile you can use svn: svn co svn://svn.code.sf.net/p/jolie/code/trunk jolie-src You can also browse the code here: https://sourceforge.net/p/jolie/code/HEAD/tree/ https://sourceforge.net/p/jolie/code/HEAD/tree/
- kaonashi 12y agoHow does this differ from say Erlang and OTP? (conceptually)
- Licenser 12y agoThat is exactly what I wondered, sadly the page does not mention Erlang/OTP whatsoever.
- fmontesi 12y agoRight, excellent question. We should put something in the FAQ. It's going to take some time to answer properly, but here are some initial pointers. Note that while I know Erlang academically I am definitely not an expert, so feel free to add more comments if you like. Both languages are based on message passing, but Erlang is functional whereas Jolie is classical imperative/stateful. Jolie provides architectural programming, e.g., you can make proxies abstracting from the behaviour of what you are composing with a language primitive. Jolie provides integration natively, e.g., with automatic data transformations between different data protocols. The contract with the developer is that if you need to change protocols or deployment information (e.g., switch from TCP/IP to Bluetooth L2CAP or in-memory communication), you just have to change a couple of lines in the deployment part of a Jolie program and the rest will continue working without modifications to the program logic (logic/deployment decoupling). Jolie has dynamic fault handling: fault handlers can be updated at runtime compositionally (higher-order code composition), which is afaik a new thing.
- jlouis 12y agoNone of those concepts seem unique to Jolie compared to Erlang, but I have yet to understand the concepts of Jolie well enough to figure out if something is conceptually different. Architectural programming: gen_server is a fine example. Integration: Erlang is opinionated but as soon as you have a lens to erlang terms, everything is easy. This is the point where Jolie may have an advantage. Dynamic fault handling is subsumed by dynamic code loading.
- fmontesi 12y ago
- alexchamberlain 12y agoShame its GPL'd.
- thesave 12y agoThe website is published under creative commons and GPL (code examples) but the Jolie codebase is published under LGPL.
- BradRuderman 12y agoIn my experience the biggest frustration when building microservices is the replicated logic across multiple languages/frameworks. For example if my microservices are in node/io.js and my app a rails app, then I can't replicate my model logic in my node services. Have you done anything in the jolie language to help this problem?
- fmontesi 12y agoIt may be the late hour here (CET), but I only kinda understood your question. What do you mean by "I can't replicate my model logic in my node services" ?
- qooleot 12y agoI think by "model logic" he is referring to MVC and things like data model relationships (and an ORM possibly), validation/casting, etc. For example, in a single programming language and framework you could say: payment.isPayPay() from a payment out of a database wrapped into a model. It has not been traditionally easy to share that business logic across languages (and by easy I mean not wrapping huge numbers of methods in http requests).
- BradRuderman 12y agoThis is correct. Business logic that exists in the model methods like in an MVC framework talking to backend services. When you have micro services in general you tend to have logic replicated in all the different micro services and even the consumers of those services.
- fmontesi 12y agoThanks, I get it now. If you use Jolie for implementing MVC, then every component is automatically a microservice (by construction from the language) and you can reuse them very easily in Jolie, Java, and Javascript inside of web browsers. If you use other languages: - if you need to use logic handled by a Jolie microservice, then you just need an API for making remote calls to that microservice. Jolie provides HTTP/JSON, HTTP/XML, SOAP, SODEP, XML-RPC, Java RMI, HTTP/GWT, and others. We have native libraries in Java (also usable in Scala) for making it even easier and look more native. You do not need to consider which protocol you will use in your logic, Jolie separates data format from logic by design. So it boils down to how easy it is to make remote calls in the "client" language. - if you have programmed your logic in another language, you will need to expose it somehow to Jolie. If you use Java or Javascript, we can reuse it natively or almost natively. Otherwise, you will need to expose the functionalities using one of the protocols above, then Jolie will immediately see it as a native service as if it were implemented in Jolie (we make no difference between stuff implemented in Jolie or not if you support any of our communication means). Is this a satisfactory answer? We can dive into examples if you have something specific in mind.
- facepalm 12y agoI stopped reading when I saw the word "SOAP".
- ch4s3 12y agoWhy? Most modern tools are pretty good at Json, but SOAP is still everywhere, especially health care. And, current support for SOAP in modern tools could be better (outside of.Net land).
- facepalm 12y agoOK, from that perspective it makes sense - if there are some APIs you just can't go without. I just don't want to touch SOAP ever again, not even with a 10 foot pole. But maybe if this makes SOAP invisible it could be acceptable - although I don't see how that could be possible.
- fmontesi 12y agoShort answer: we usually don't use SOAP unless it is strictly necessary in your system. We have simpler and/or more efficient protocols. Long answer: We do not use SOAP when it is not strictly necessary. Most Jolie programs use SODEP (our own open binary protocol) or HTTP/JSON or HTTP/XML. You do not need to deal with this manually, you just tell Jolie "use HTTP" or "use SODEP" in the deployment part. For example, this is how you expose your service in SODEP: inputPort MyService { Location: "socket://localhost:80" Protocol: sodep Interfaces: MyIface } and this is how you get the same thing but in HTTP: inputPort MyService { Location: "socket://localhost:80" Protocol: http Interfaces: MyIface } If you use Jolie to provide a SOAP service, it will most probably be completely invisible. You just have to choose soap and you are done: inputPort MyService { Location: "socket://localhost:80" Protocol: soap Interfaces: MyIface } Jolie will take care of using the right data formats without you noticing. If you need to access an external SOAP service, there are many cases in which it can be invisible, but also many other cases in which you will have to tell Jolie some extra parameters in case some extensions or weird details need to be used.
- al2o3cr 12y agoLooks interesting, but "It is used in Computer Science research and teaching at many universities around the world." turns into "It's had papers about it published by the same handful of researchers for the last decade" when you actually look at the references. Consider toning down the sales pitch and focusing on the language.
- cguidi 12y agoWe are in the middle, you know :-) Usually the academic part ask to us to focus more on the research topics instead of the language details (they usually call them "details" :-)). We believe both of the aspects are very important. There are formal models behind the language which are, and will be, very useful for building analysis and verification tools