Ballerina language promises to improve app integration

The Ballerina language is new to the programming world. It promises to streamline integration development for enterprise apps. It supports several primitives designed to reduce much of the burden Java developers typically face when coding against APIs through JSON, REST, and XML interfaces.

It’s still early, but the Balerina language has attracted the support of Google, WSO2, Bitnami, and the Apache OpenWhisk group. The companies recently convened in San Francisco for the inaugural Ballerinacon to discuss the open source project and other details that support the language. What will Ballerina mean for Java developers? TheServerSide caught up with Tyler Jewell, CEO of WSO2, to find out.

So why do we need another programming language?

Tyler Jewell: The Ballerina language was born out of frustration with programming frameworks and integration products that embed programming logic within YAML, XML, or other configuration-based files. These approaches disrupted the developer flow, requiring special purpose tools and debuggers that took developers away from focusing on iterative development.

One had to either choose robust, complex, and heavy server products for managing integrations or use a general-purpose language with a framework that varied by programming language and objectives. There has not existed a way to get agility with rapid code development that runs microintegration servers for message brokering, service hosting, and transaction coordination.

Ballerina is an attempt to combine the agility of a type-safe programming language with the syntax of integration sequence diagrams. Once compiled, the resulting binaries embed microengines that perform inline integration semantics such as mediation, orchestration, transformations, asynchrony, event generation and transactions.

Finally, working with the Ballerina language is intended to be cloud-native. The language has constructs that define the architectural environment, so the compiler understands the logical environment the application will be running within. This enables the compiler to generate numerous runtime environment artifacts that are typically generated by continuous integration solutions.

How are organizations using the Ballerina language and who are some of the leading companies adopting or supporting it?

Jewell: Like most languages, the early community takes a number of years to nurture. The first production-ready version of the language was made available in May, and there are numerous early contributors and users. 

Today, the early adoptions have happened in two areas:

1. Ballerina now powers WSO2’s API microgateway engine, which is for enabling per-API gateway and management. Dozens of WSO2’s enterprise customers are actively deploying and using it.
2. Early cloud-native and Kubernetes adopters who have complex integration scenarios do not want an ESB within their orchestrator. Ballerina is a more distributed form of an ESB.

We have seen early contributions to the ecosystem from the community and Google, Bitnami, Honeycomb, and Apache OpenWhisk were all early contributors and speakers at yesterday’s Ballerinacon.

There are Fortune 500 companies that have contracted support for deploying Ballerina on major applications, but they are not yet ready to share with the public who they are.

How does the Ballerina language compare and contrast with other languages like Java, Go or Scala?

Jewell: Ballerina’s language design principles are to focus on simplifying issues tied to integrating systems over a network. As such, the core design principles are:

Sequence Diagrammatic

Ballerina’s underlying language semantics were designed by modeling how independent parties communicate via structured interactions. Subsequently, every Ballerina program can be displayed as a sequence diagram of its flow with endpoints, including synchronous and asynchronous calls. The Ballerina Composer is an included tool for creating Ballerina services with sequence diagrams. Sequence diagrams are a reflection of how designers and architects think and document interconnected systems. Ballerina’s syntax is structured to let any tool or system derive a sequence diagram, and subsequently the way a developer thinks when writing Ballerina code encourages strong interaction best practices. This theory is elaborated upon in Sanjiva Weerawarana’s blog.

Concurrency Workers

The Ballerina language’s execution model is composed of lightweight parallel execution units, known as workers. Workers use a full non-blocking policy where no function locks an executing thread, such as an HTTP I/O call awaiting response. These semantics manifest sequence concurrency where workers are independent concurrent actors that do not share state but can interact using messages. Workers and fork/join language semantics abstract the underlying non-blocking approach to enable a simpler concurrency programming model.

Network Aware Type Safety

Ballerina has a structural type system with primitive, object, union, and tuple types. Network systems return messages with different payload types and errors. Ballerina’s type system embraces this variability with an approach based on union types. This type-safe model incorporates type inference at assignment to provide numerous compile time integrity checks for network-bound payloads.

DevOps Ready

Over the past 15 years, best practices and expectations on the associated toolset that a language provides have evolved. Now, a language is not ready for adoption unless it includes unit test framework, build system, dependency management and versioning, and a way to share modules of reusable code. Ballerina includes all of these subsystems as part of its core distribution so that there is no risk of community drift, which is what happens when the ecosystem needs to build tools on top of a language, instead of designing it within the language.

Environment Aware

The Ballerina language and its components are intended to be used within distributed, event-driven architectures. Subsequently, each service written within Ballerina is residing in an environment that may also include legacy services, service meshes, orchestrators, API gateways, identity gateways, message brokers and databases. Ballerina’s language and annotation extension are intentionally environment-aware, treating these other components as syntactical objects and relationships as decorated annotations. By having the language and build system be environmentally aware of other components surrounding our service, we can generate essential artifact code ahead of CI/CD, perform data and integrity checks around network-bound payloads, and pre-package dependent but not yet deployed components as part of the Ballerina binary.

In what ways do you see Ballerina complementing or replacing other programming languages?

Jewell: More than 50% of the time and cost for digital transformation and API projects within enterprises is now integration. When resilient logic and microservices need to be built, Ballerina doesn’t impose much of the scaffolding tied to data formats, network interactions, and resilience. This makes the runtime lighter and developer productivity for coding the solutions higher. Developers will continue to use the languages that they are comfortable with, but we see Ballerina as providing a simpler experience for microservices, API development, system administrator network scripting, and composite development.

What are some of the specific features of the Ballerina language that make it useful for integration?

Jewell: Let me highlight a few of the important ones:

1. Network-aware type systems make it easier to program data types against remote APIs.
2. Intuitive mapping of complex data structures into primitive value and union types makes data transformation statically typed and intuitive to follow.
3. Treating services and endpoints as first-class constructs, by recognizing that network locations and APIs are understood by the compiler and runtime.
4. Built-in compiler support to layer in failover, retries, circuit breakers, load balancing, and distributed microtransactions for communicating with endpoints.
5. Broad and native support for a variety of over the wire protocols, enabling service and endpoint abstractions that feel local.

What new concepts would a typical Java developer need to learn to make the most of Ballerina over and above the syntax and grammar?

Jewell: It’s more about what things a Java developer no longer needs to understand! The underlying value type system makes JSON, XML, tables, records, maps, and errors primitives so that they do not require libraries to work with these fundamental data structures. This enables developers to do a lot of data structure manipulation using simple constructs within the source code that is unavailable in most other languages.  

Also, the union type system makes it possible for a type to be multiple different types, such as “string | error,” as working over a network has many situations where a single request can return different kinds of payloads, each suited to a different data structure. So, union types enable someone to make a single request and have the response be mapped into any number of different types. Developers then have to learn some techniques about determining the actual type returned when a union type is present.

What are some of the best practices for learning and implementing Ballerina apps?

Jewell: The language developers have done a great job of providing two sets of examples:

1. More than 100 Ballerina by Examples … which go into each nuance of the language’s syntax with a complete example.
2. A growing list of Ballerina by Guides … which provide an end to end development experience for tackling different types of enterprise integration scenarios.

What are some of the current or planned tools and IDEs for the Ballerina language?

Jewell: Ballerina has:

1. A fairly advanced VS Code plugin that offers a wide range of language server IntelliSense capabilities.
2. A similar capability for IntelliJ.
3. The Ballerina Composer, which lets you visually map any Ballerina service as a sequence diagram along with monitoring execution.
4. A debugger that works with any Ballerina runtime.
5. Built-in package management, Ballerina Central for sharing packages, package versioning, and package build management.
6. Test frameworks for running unit tests and mocks for hosted services written in Ballerina.
7. A documentation framework for auto-generating different types of documentation from within Ballerina code.

How do you expect the future of the Ballerina language to evolve?

Jewell: The Ballerina language is production ready now, but the syntax has not yet achieved a 1.0 lock. The designers are working towards a 1.0 release, where they will then provide long-term backwards compatibility. We hope that this level of stability is reached by the end of the year.

We anticipate the language to continue to evolve and investments being made to optimize its capabilities for stateful services, serverless execution, complex multi-tier compensations, and optimizations for running in large-scale orchestration systems.