
Show HN: Ballerina – Cloud Native Programming Language - TylerJewell
http://ballerina.io
======
TylerJewell
Ballerina is a compiled, type safe, and concurrent programming language to
make it easy to write integration services, which are typically the glue
between connecting different endpoints with distributed transactions, reliable
messaging, mediation, transformation, and orchestration.

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.

------
TekMol
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?

~~~
sanjiva
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...](https://ballerina.io/res/Ballerina-Language-Specification-
WD-2015-05-01.pdf).

Feedback welcome!

~~~
TekMol
Thanks!

------
gigatexal
This looks really interesting. Is it production ready? What companies, if any,
are using this in production?

~~~
TylerJewell
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.

------
fiatjaf
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.

~~~
ycrnet
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/](https://central.ballerina.io/). Also take a
look at some guides available at [https://ballerina.io/learn/by-
guide/](https://ballerina.io/learn/by-guide/)

~~~
fiatjaf
Whoa, I wasn't expecting for that. I'll surely check it out.

~~~
TylerJewell
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.

~~~
fiatjaf
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.

~~~
TylerJewell
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.

