Ballerina is a modern programming language focused on integration. It aims to make network-aware programming and data processing easier through features like built-in support for network services, clients, listeners and endpoints. The language sits between static and dynamic typing, with a structural and mostly static type system. Concurrency is also designed to be natural for programmers through workers and futures. The language is being developed with an integrated standard library, tools, and runtime to be a complete solution for network-centric applications and microservices.

1. Ballerina: A modern programming
language focused on integration
Sanjiva Weerawarana, Ph.D.
Lead Ballerina
Founder & Chairman, WSO2

2. Overview
• Motivation
• Key differences
• Type system
• Errors
• Concurrency
• Networking
• And more
• Beyond the language
• Standard library, developer tools, testing, documentation, observability

3. Motivation: Why yet another language?
• Digital transformation
• Everything is a network service
• Produce, not just consume network services
• Minimalization of computing
• Hardware: Bare metal  VMs  Containers  Serverless
• Application architecture: SOA  Microservices  Functions
• Integration: ESB  Service meshes
• Middleware is dead; middleware is everywhere
• Servers  sidecars  code

4. New language
• Most widely used languages fall into one of the two ends of the spectrum
• Too rigid: Statically but nominally typed, often object oriented like Java, C#, Go
• Too flexible: Dynamic languages with little or no static typing like Python,
Javascript (but improved with Typescript), PHP
• Focus is not on the problems that are clear and present today
• Ballerina sits in the middle with
• Structural, mostly static strong typing
• Blend of functional, imperative and object orientation
• Strong focus on data oriented programming, network awareness
• Concurrency made simple for normal programmers

5. Design inspirations
• Sequence diagrams the core conceptual model for programming
• Many existing languages, including Java, Go, C, C++, Rust, Kotlin, Dart,
Typescript, Javascript, Flow, Swift, RelaxNG, Midori, DLang and more

6. Design principles
• Code with equivalent both text and graphic syntaxes
• Embrace the network with network friendly data types, resiliency and
syntax
• Make programs secure by default
• Little room for best practices or “findbugs”
• No dogmatic programming paradigm
• Familiarity, where appropriate
• Easy for non-rocket scientist programmers
• Mainstream concepts & abstractions, not research

7. Status
• Core language design getting closer to being done
• What I am explaining today is a mixture of what is available for download and
what is pending implementation
• Core language is stable but a few more breaking changes are coming 
• Implementation
• Core language
• Stdlib
• Tools
• Team
• 50+ engineers for last 2+ years with higher bursts

8. Hello, World main
% ballerina run hello.bal KubeCon

9. Hello, World main

10. Hello, World service
$ ballerina run helloservice.bal
Initiating service(s) in 'helloservice.bal'
[ballerina/http] started HTTP/WS endpoint 0.0.0.0:9090

11. Type system

12. Universe of values
• Simple
• (), boolean, int, float, decimal, string
• Structured: create new values from simple values
• Lists (arrays & tuples), mappings (maps & records), tables, xml and errors
• Behavioral: bits of Ballerina programs as values
• Functions, futures, objects, services and typedesc
• Streams(*), channels(*)

13. Values and storage
• Some values are stored only conceptually
• E.g. 3.1415 is a float value that doesn’t have a material “storage” location
• Simple values are always immutable
• Certain values are stored somewhere and that location is how you
identify the value
• Reference values
• All structured values and behavioral values

14. Types and type descriptors
• Types are names for type descriptors
• Type descriptors describe a set of value that belong to that type
• Do not add new values to universe
• Membership
• Given value can be in any number of sets, therefore have any number
of types

15. Types and shapes
• Values have a storage location (thereby another identity) and are
sometimes mutable
• Types only worry about ”shape” of a value
• Different basic types have different shapes
• Ignores storage location and mutability
• Only difference for reference values, not for simple values (as no storage)
• Type = set of shapes
• Subtype = subset

16. Types, values & shapes
• Value “looks like a type” at a particular point of execution if its shape
is in the type
• Value “belongs to a type” if it ”looks like a type” and no mutation can
change its shape so it no longer belongs to the type

17. Other type descriptors
• Singleton
• Union
• Optional
• any
• anydata
• byte
• json

18. any
• Describes type consisting of all values except error values
• Thus, any|error is a type descriptor for all values

19. anydata
• Type of all pure values other than errors
• Equal to:
• () | boolean | int | float | decimal | string | (anydata|error)[] |
map<anydata|error> | xml | table
• Used for message passing

20. byte
• Union of 0 | 1 | .. | 255

21. json
• Union of
• string | boolean | int | float | decimal | map<json> | json[] | ()

22. Errors

23. Error handling
• Different languages have different approaches
• Great blog by Joe Duffy on Midori error handling
• Two kinds of errors
• Abnormal errors (bugs)
• Normal errors

24. Abnormal vs. normal errors
• Abnormal errors
• Should not normally happen
• Little the programmer can do about them
• Normal errors
• Statically typed
• Explicit control flow
• Normal errors cannot implicitly become abnormal and vice-versa

25. panic/trap for abnormal errors
• Less convenient form than try-throw-catch
• Abnormal errors are not for people to play with!
• All other errors must be statically declared, even in concurrent
interactions
• Programmer must be aware and must handle
• Not allowed to ignore error returns with union typing

26. Concurrency

27. Making concurrency natural
• Most programming languages have made concurrency special
• Everything starts with one thing and then becomes concurrent
• Every executable unit (function, method, resource) is always
concurrent
• Collection of workers
• Sequence diagram with concurrent actors!
• Worker to worker communication allows coordination

28. Non-blocking runtime
• Ballerina does not rely on callbacks for high performance or scale
• User merrily programs as if they hold execution until delaying action
(I/O etc.) completes
• Runtime scheduler manages scheduling of ready to run strands to
threads

29. Strands
• Started by a worker or by starting a function call asynchronously
• “strand of workers”
• Gets scheduled to a thread for execution
• Represents a standard call stack
• Every named worker starts a new strand
• Represented by a future which can be used to get return value of
initial worker

30. Futures
• Futures represent strands
• Type is the return type of the worker running in the strand, including
any errors
• A named worker defines a variable of type future<T> where T is the
return type of the worker.
• Futures are first-class- so can be passed as parameters etc.

31. Communicating between workers
• Complex interactions allowed only when workers defined lexically
together
• Deadlock avoidance requires this
• Looking into session types to possibly strengthen this
• Values of type anydata|error can be communicated via cloning over
anonymous channels
• Errors (including panics) can propagate across workers
• Blocking & unblocking variants for send

32. Concurrency safety
• Use immutable data when possible
• Lock construct for explicit locking
• Implements two-phase locking
• Important: physical concurrency in business use cases is limited
• High concurrent users is the common scenario
• More work TBD for this area
• Uniqueness typing (Swift), Ownership types (Rust), STM, ..
• Ideal goal is Ballerina code will not fail with race conditions under load

33. Networking

34. Language abstractions
• BSD sockets
• Network communication is not just a byte stream!
• Messages, protocols, interaction patterns
• Endpoints are network termination points
• Inbound or ingress
• Outbound or egress
• Ballerina models these via Listeners, Clients and Services

35. Graphical representation
• Endpoints are represented as actors in the sequence diagram
• Usually Ingress endpoint on left, egress endpoints on right of workers
• Any network interaction shows up as a line to/from a worker to an
actor representing endpoint

36. Clients
• Clients are abstraction for egress endpoints
• Defined by an object with “remote” methods
• Methods with a “remote” qualifier
• Syntax:
• Text: var result = client->actionName (args);
• Graphically: line from worker to client

37. Outbound reliability & resiliency
• Fallacy of distributed computing: network is reliable
• Ballerina comes with library of tools to manage
• Load balancing
• Failover
• ..
• Implemented as libraries that layer on underlying clients

38. Listeners and services
• Listeners are responsible for establishing network ports (or other
concepts) and managing a set of services that are attached to them
• Listeners are objects that implement system interface
• Module listeners
• Listeners attached to module lifecycle
• Makes services equal citizens as main()

39. Services
• Collection of handlers for inbound requests
• Resource functions
• Listener responsible for dispatching requests to correct service and
resource
• Services are like singleton objects and are first class values

40. Service typing
• Listener to service relationship can be complex
• One listener can manage multiple service types, one service type can be
attached to different kinds of listeners
• Current service typing is done by extensions (annotations)
• WIP to improve

41. And more …

42. Yeah there’s a few more things ..
• Integrated LINQ-like query for table values
• Streaming query and stream processing
• Security abstractions for secure services and network data
• Distributed transactions, both ACID and compensating
• Long running execution support with checkpointing
• Language extensibility with environment binding and compilation
extensibility

43. Beyond the language

44. “Batteries included” standard library
• ballerina/auth
• ballerina/cache
• ballerina/config
• ballerina/crypto
• ballerina/file
• ballerina/grpc
• ballerina/h2
• ballerina/http
• ballerina/internal
• ballerina/io
• ballerina/jdbc
• ballerina/jms
• ballerina/log
• ballerina/math
• ballerina/mb
• ballerina/mime
• ballerina/mysql
• ballerina/reflect
• ballerina/runtime
• ballerina/sql
• ballerina/swagger
• ballerina/system
• ballerina/task
• ballerina/test
• ballerina/time
• ballerina/transactions
• ballerina/websub

45. Beyond code
• Editing & debugging
• VSCode and IntelliJ plugins
• Testing framework
• Observability: metrics, tracing, logging
• Documentation generation
• Modularity, dependencies, versions, building & sharing

46. Implementation
• Compilation process
• Mid level intermediate representation (BVM bytecodes) into library (.balo) as portable object
format
• Link & execute via multiple paths
• Link and execute in Java based interpreter (available now)
• Native binary via LLVM (in progress)
• WebASM, Android, embedded devices, MicroVM as future targets
• Bootstrapping compiler into Ballerina in (slow) progress
• Extensible architecture for compiler to allow 3rd party annotation processing to become
part of compilation process, e.g. Docker/K8s
• IDEs supported via Language Server Protocol
• Plugins for VS Code, IntelliJ and standalone browser-based Composer

47. Compiler architecture

48. Conclusion

49. Ongoing work
• Concurrency safety
• Immutable types, STM, uniqueness types, ownership types
• Communication safety
• session types
• Workflow related
• Forward recoverability via checkpoint/restart
• Compensation
• Parametric typing
• Internationalizing the grammar

50. Timing
• Few more breaking changes expected but not anywhere as dramatic as
0.970, 0.980 or 0.990
• Thank you for your patience!
• Moving some features to ”Experimental” category for 1.0 timeframe
• 1.0 is expected by Summer(-ish) 2019
• Pretty much 3 years since birth
• Full native compilation of 1.0 will take longer

51. Summary
• Ballerina is building a modern industrial grade programming language
• For future with lots of network endpoints
• Type system is designed to make network data processing easier
• First class network services along with functions/objects
• Framework to encourage more secure code
• Fully open source and developed openly