Show HN: Ballerina – Cloud Native Programming Language(ballerina.io)
ballerina.io
Show HN: Ballerina – Cloud Native Programming Language
http://ballerina.io
4 comments
As a language nerd, I had to take a look. But I really can't figure out what this is about.
"Ballerina makes it easy to create resilient services that integrate and orchestrate transactions across distributed endpoints."
Is it real or a joke? It sounds like a markov chain generator was fed with tech mumbo jumbo and then generated this?
If it's real - what is the no nonsense description?
And who is behind it?
"Ballerina makes it easy to create resilient services that integrate and orchestrate transactions across distributed endpoints."
Is it real or a joke? It sounds like a markov chain generator was fed with tech mumbo jumbo and then generated this?
If it's real - what is the no nonsense description?
And who is behind it?
I'm the lead designer of Ballerina.
Its a real language :-). Please check the spec out here: https://ballerina.io/res/Ballerina-Language-Specification-WD....
Feedback welcome!
Its a real language :-). Please check the spec out here: https://ballerina.io/res/Ballerina-Language-Specification-WD....
Feedback welcome!
Thanks!
No, you're just trying to be a jerk. It's difficult to explain what a service does in a single sentence, but this one makes perfect sense, albeit generical.
Oh and I didn't answer the question of who's behind it - this is being lead by WSO2, of which I'm the chief architect.
This looks really interesting. Is it production ready? What companies, if any, are using this in production?
We are using it in production at WSO2 now - we have gateways and web site APIs running it.
We just made a 0.970.0 release last week which contains significant alterations. The language and runtime have been in iterative design and test for a couple years.
We are just now putting live ballerina.io so that we can start working within the community to gain adoption. A number of WSO2 customers are working with it in development and pre-production, but we asked them to not consider production deployments until the rework was done.
We hope to hit a 1.0 milestone by the end of the year where we will guarantee backwards compatibility.
We do find the runtime to be extremely stable with throughput numbers about 5x higher than equivalent ESBs, and we are running long term stability tests that are doing well. We'll publish all of these results soon, too.
We just made a 0.970.0 release last week which contains significant alterations. The language and runtime have been in iterative design and test for a couple years.
We are just now putting live ballerina.io so that we can start working within the community to gain adoption. A number of WSO2 customers are working with it in development and pre-production, but we asked them to not consider production deployments until the rework was done.
We hope to hit a 1.0 milestone by the end of the year where we will guarantee backwards compatibility.
We do find the runtime to be extremely stable with throughput numbers about 5x higher than equivalent ESBs, and we are running long term stability tests that are doing well. We'll publish all of these results soon, too.
I want a "programming language" (or better, a platform) that would natively integrate different services, like Google Drive, Dropbox, Slack, Trello, GitHub, Dropbox and so on like they were all in the same machine.
You are in luck, ballerina is a platform carefully designed to address most of the integration problems we face. You can have a look at ballerina central where connectors are available which are needed to integrate with third party apps like, Git twitter etc. https://central.ballerina.io/. Also take a look at some guides available at https://ballerina.io/learn/by-guide/
Whoa, I wasn't expecting for that. I'll surely check it out.
Yeah, the way it works in Ballerina is that an endpoint is a keyword that can create an object that represented a networked location. This could be one of three things - either the caller that invoked your service, the service you author which is listening as an endpoint, or a service you want to invoke.
For the services that you want to invoke, you can create endpoint objects of different types. The objects during initialization use connectors to establish the communication. It's like doing a constructor call in an OOP. You can import different packages the way you would with any language and shared packages are available on central.
Once you have one of those endpoint objects, you can do type safe invocations against it. So you might create a Twitter connection creating a "tweeter" object. That connector then has functions which can be invoked, "tweeter -> tweet (params);". This returns a data structure that is strongly typed and mapped to the payload expected in return from the service.
It's also pretty simple to write your own packages which have your own connectors. The push / pull dynamics of packages with central are similar to Elk or DockerHub, but applied to code modules.
For the services that you want to invoke, you can create endpoint objects of different types. The objects during initialization use connectors to establish the communication. It's like doing a constructor call in an OOP. You can import different packages the way you would with any language and shared packages are available on central.
Once you have one of those endpoint objects, you can do type safe invocations against it. So you might create a Twitter connection creating a "tweeter" object. That connector then has functions which can be invoked, "tweeter -> tweet (params);". This returns a data structure that is strongly typed and mapped to the payload expected in return from the service.
It's also pretty simple to write your own packages which have your own connectors. The push / pull dynamics of packages with central are similar to Elk or DockerHub, but applied to code modules.
Ok, now I'm trouble. How is this different from using an API wrapper for any of these services in any other programming language?
I'll read more on ballerina.io anyway later to see if I can answer this.
I'll read more on ballerina.io anyway later to see if I can answer this.
I doubt you are trouble, it's a natural question.
On the surface every networked call feels like a method call, so absolutely, within any other language it could be done with a nicely prepared API wrapper for a similar type of connector. And, ultimately, that is what happens within a lot of ESB products that standardize how a connector should be deployed, versioned, and consumed by client applications within that environment.
Beyond that, though, the approach to the language design and the underlying implementation of connectors offers simplicity benefits that should make consuming new connectors easier and more reliable. A few things: 1. All network-bound calls are required to use arrow `->` notations instead of dot `.` to make some important distinctions. One is that sequence diagrams make this distinction and we can auto-generate sequence diagrams from any code file as the code structure is designed to reflect how integrators model their services.
2. Treating an endpoint as a native keyword and how that endpoint object is initialized within the language makes it opinionated, which ultimately makes configuration of some complex connectors simpler than what would be seen in API wrappers. If you take a look at the circuit breaker example, the circuit breaker is added as a configuration parameter to an outgoing HTTP connection. Of course, other languages can be opinionated about this as well, but they almost always delegate this to an add-on framework, and there are always some minor quirks to how frameworks work with their language of choice. So we get to bypass that and ultimately the syntax gets minimized to the point where it's easier to embrace and learn.
3. The underlying concurrency model in the language's runtime is based upon workers for parallelization, which are how sequence diagrams are modeled. Languages like Java map threads to classes. Node maps threads to the event processor, and so forth. When an HTTP -> call is made, we can do some nice internal optimizations such that while the code that you write will see that network call as a blocking call, behind the scenes, the runtime treats the outbound request as one worker and receiving the response as a second worker. Each worker is mapped to a different thread and you get some nice throughput mechanics because the system's scheduler releases a thread when the request is made. Because we know that any connector's invocation is going over a network with this syntax, there are interesting thread scheduling algorithms we can implement. We are seeing about 5x the TPS with a simple routing service built in Ballerina vs. the same type of service that we would implement in an ESB like Camel or Apache.
There are other thing that the designers will probably comment on, too.
On the surface every networked call feels like a method call, so absolutely, within any other language it could be done with a nicely prepared API wrapper for a similar type of connector. And, ultimately, that is what happens within a lot of ESB products that standardize how a connector should be deployed, versioned, and consumed by client applications within that environment.
Beyond that, though, the approach to the language design and the underlying implementation of connectors offers simplicity benefits that should make consuming new connectors easier and more reliable. A few things: 1. All network-bound calls are required to use arrow `->` notations instead of dot `.` to make some important distinctions. One is that sequence diagrams make this distinction and we can auto-generate sequence diagrams from any code file as the code structure is designed to reflect how integrators model their services.
2. Treating an endpoint as a native keyword and how that endpoint object is initialized within the language makes it opinionated, which ultimately makes configuration of some complex connectors simpler than what would be seen in API wrappers. If you take a look at the circuit breaker example, the circuit breaker is added as a configuration parameter to an outgoing HTTP connection. Of course, other languages can be opinionated about this as well, but they almost always delegate this to an add-on framework, and there are always some minor quirks to how frameworks work with their language of choice. So we get to bypass that and ultimately the syntax gets minimized to the point where it's easier to embrace and learn.
3. The underlying concurrency model in the language's runtime is based upon workers for parallelization, which are how sequence diagrams are modeled. Languages like Java map threads to classes. Node maps threads to the event processor, and so forth. When an HTTP -> call is made, we can do some nice internal optimizations such that while the code that you write will see that network call as a blocking call, behind the scenes, the runtime treats the outbound request as one worker and receiving the response as a second worker. Each worker is mapped to a different thread and you get some nice throughput mechanics because the system's scheduler releases a thread when the request is made. Because we know that any connector's invocation is going over a network with this syntax, there are interesting thread scheduling algorithms we can implement. We are seeing about 5x the TPS with a simple routing service built in Ballerina vs. the same type of service that we would implement in an ESB like Camel or Apache.
There are other thing that the designers will probably comment on, too.
These are all capabilities that are usually built into integration products around a language, though these concepts are baked into the syntax and the language design.
The platform portion contains additional runtimes components for enabling this functionality including an API gateway, a message broker, a transaction coordinator, and a bridge for brokering transactions to services that are written in other languages.
There are roughly 100 committers. It's a lot of people that were involved in Apache Synapse and WSO2 ESB.