Some details about how Ballerina is different from other programming languages such as Java, Go, Rust, Kotlin, etc.

1. Ballerina is not Java (or Go or ..)
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & Chief Architect; WSO2
BallerinaCon – San Francisco, July 18, 2018

2. Motivation: Why yet another language?
• Digital transformation
– Everything is a network service
– Produce, not just consume network services
– Every business has to become a software company
• Minimalization of computing
– Hardware  VMs  Containers  Serverless
– SOA  Microservices
– ESB  Service meshes
• Middleware is dead; middleware is everywhere
– Servers  sidecars  code
7/21/2018 2

3. Design motivation: Sequence diagrams
• Used to describe how complex systems work
• Why not use that as the abstraction for code?
7/21/2018 3

4. Design principles
• Code with equivalent both text and graphic syntaxes
• Do not try to hide the network
• First class support for network data types
• Make programs network resilient by default
• No room for best practices or “findbugs”
• Make programs secure by default
• No dogmatic programming paradigm
• Mainstream concepts & abstractions, not research
7/21/2018 4

5. Unusual aspects of Ballerina
• Structural type system with network friendly types and unions
• First-class nature of application level network abstractions
• Graphical with sequence diagrams
• Sequence diagram based parallelism model
• Errors and exceptions
• Traditional middleware is in the language
– API mgmt, ESB like integration, data integration, streaming analytics, identity
• Language extensibility with environment binding and compilation extensibility
• Integrated query and streaming query
• Language level security abstractions
• Event driven runtime
• Not afterthoughts:
– Documentation
– Version management
– Dependency management
– Testing
7/21/2018 5

6. Values
• Simple values: (), boolean, int, float, decimal, string
• Structured values: tuple, array, map, record, table, xml, error
• Behavioral values: function, future, object, stream, typedesc
7/21/2018 6

7. Simple values
7/21/2018 7
10, 98
0 100.98
10.0 100.980
“would”
“wouldn’t” true false
string
decimal
float
int
boolean
()

8. Structured values
7/21/2018 8
{{“x”: y,
“a”: 20},
{“foo”:
“bar”}, …}
{[10, “20”],
(“x”, 20,
true), ...}
mappings
lists
{ ...}
tables
{ ...}
errors
{<f>1</f>,
<a>b</a>,
…}
xml

9. Behavioral values
• function
• future
• object
• stream
• typedesc
• (few more coming)
7/21/2018 9

10. Type descriptors
• A type descriptor describes a set of values
– Membership test for a set
• A type is a label for the set
• Note: a given value can be in any number of sets
7/21/2018 10

11. Basic types
• Names for the fundamental value sets
– int, float, …
• Type constructors
– map, record, …
7/21/2018 11

12. Broad vs. narrow type
string s = “x”;
• What type is the value “x”?
– Narrow type: Singleton type with just that value: { “x” }
– Broad type: string
7/21/2018 12

13. Mapping types
• Mappings are collections of (name, value) pairs
• Variations
– Open vs. closed mappings
– Required vs. optional fields
• “record” type constructor
– Collection of mandatory and optional named fields of any types
– Open if desired
• “map” type constructor
– Any fields but all values of a single type
– Always open
• Covariant subtypes
– Storage type
7/21/2018 13

14. List types
• Ordered sequence of values
• Variations: fixed length vs. variable length
• Array constructor
– Single member type
– Fixed or variable length
• Tuple constructor
– Sequence of values of various member types
– Fixed length
7/21/2018 14

15. XML
• Minimalistic but powerful native xml type
• Non-traditional XML architecture
– xml is sequence of things that appear in XML (elements, comments,
text, ..)
– Elements do not contain references to parent or siblings and same
element can appear in multiple xml values
– No node identity, no text nodes (just strings)
– Namespaces married to Ballerina qualified name architecture
• Literal XML values, reading/writing
7/21/2018 15

16. Tables
• Tabular data
– Programmatically generated & manipulated
– Database connectors to load/store tables
• Integrated SQL-like query, ala C# LINQ
– In-memory database
– Table rows are just records (no ORM)
7/21/2018 16

17. Errors
• Errors are their own value space
– (reason (string), details (map), stacktrace)
7/21/2018 17

18. Other types
• Unions
• Finite types
• Optional
• json
• byte
• any
7/21/2018 18

19. Union types
• Type defined by union of two or more other types
– Remember, a type is name for a set of values
• E.g.:
type IntOrString float | string;
IntOrString v1 = “yo”;
IntOrString v2 = 3.141592;
7/21/2018 19
0 100.98
“would”
“wouldn’t”

20. Finite types
• Remember, a type is name for a set of values
• Sets can have finite number of values as well
type ThisOrThat “this” | “that” | 17;
7/21/2018 20

21. Optional types
• Variable can be declared to holding a value of a particular
type or no value at all
int? foo;
Person? bar;
• No null pointers in Ballerina!
7/21/2018 21

22. json
• json is just a union
– () | int | float | string | map<json> | json[]
• json objects are most commonly used
– map<json>, but subtyped to an open record with non-mandatory
fields in most cases
– Very useful for man-in-the-middle network scenarios
• With json being within the type system, no data binding
concept needed for json
7/21/2018 22

23. byte
• Just a predefined union:
type byte 0 | 1 | … | 255;
• We avoid all the problems of different kinds of math for
different numeric sizes
7/21/2018 23

24. any
• Predefined name for union of all built-in and user-defined
types
7/21/2018 24

25. Casting and conversions
• Casting is defined by set membership: if the value is a
member of the L-Value type then it can be casted, otherwise
no
– Value doesn’t change (of course)
• ZERO automatic conversions
– Not even int -> float
• Future: data transformation constructs
7/21/2018 25

26. Type matching
• Union typed expressions have to be separated out before use:
match expression {
pattern [var] => statement;
pattern [var] => statement;
..
}
• Or within an expression:
expression but { pattern [var] => expression }
7/21/2018 26

27. Errors and error lifting
• Errors are its own value space
• Can be returned or thrown
– Often returned as T | error
– Throwing is discouraged and meant to be used rarely
• Error lifting
– Many functions return ResultType | error
– Check expression: check expression
• If error return immediately, else error is eliminated from type set
7/21/2018 27

28. Nil & error lifting navigation
• Navigating deep hierarchies is common in integration code
• Navigating through optional types are nil-lifted by “.”
operator: a.b.c
• Navigation is both nil and error lifted by “!” operator: a!b!c
• Why?
– Combination of optional types and type matching makes it impossible
to have a null reference in Ballerina
– Nil & error lifting make those rules palatable
7/21/2018 28

29. NETWORK
7/21/2018 29

30. Endpoints
• Endpoints represent network termination points for incoming network
interactions or outgoing network interactions plus set of typed
interactions that are allowed
• Ingress vs. egress endpoints
• Egress endpoints represent remote systems
– Offer a set of actions for interaction with them
• Ingress endpoints are network entry points to a Ballerina runtime via a
registered service
– Calls are delivered to a particular resource in a service
– Offers incoming endpoint list of actions to reply/message
• Modeled as an actor in sequence diagram
7/21/2018 30

31. Network interactions
• Programmer needs to be made aware that this is a network
call
– Graphically line from a worker to an endpoint
– Textually:
var result = epName->actionName (args);
• If any errors occur they need to be type matched and handled
7/21/2018 31

32. Outbound resiliency
• Failure is normal in network interactions
• Endpoints are logical
– Group them for load balancing, failover or other behaviors
• Circuit breaking, bulk-heading, timeouts, load management all
part of endpoint architecture
7/21/2018 32

33. Services & resources
• Service is a collection of resources where each resource is
network invokable via ingress endpoints
• Services must be attached to an endpoint to be invoked
• Responses must be via endpoint and not by returning values
– Responses may not go
7/21/2018 33

34. Ballerina graphical notation
• Sequence diagrams focused on showing worker and endpoint
interactions
– Endpoints represent network services
• Each worker is sequential code
– We can zoom in graphically but its really just code
• Not meant to be used for low-code / no-code or by non-
programmers
– Meant to make it easier to understand complex distributed
interactions
7/21/2018 34

35. Always-on parallelism
• Every executable entity (function, method, resource) is a
collection of workers
– Line in a sequence diagram
• Each worker is a independent execution context
• All workers of a function execute concurrently when the
function is called
7/21/2018 35

36. Always-on parallelism
7/21/2018 36

37. Blocking function invocation
• Protocol
– Initialization: start endpoints
– Start concurrent workers
– First one to return will release caller
• Others continue to completion
• If no one completes (e.g. due to failures) function call fails
with “call failed” exception
• Results in a cactus stack instead of a traditional call stack
7/21/2018 37

38. Non-blocking invocation and futures
• Any function can be called in a non-blocking way:
future<T> f = start functionName (args)
• Wait for completion, cancel, get return values via typed future
7/21/2018 38

39. Worker to worker communication
• Via anonymous channels, non-blocking for send, blocking for
receive
• More comprehensive patterns coming
7/21/2018 39

40. Implementation
• Compiler produces mid level intermediate representation
(BVM bytecodes) into library (.balo)
– Portable object format
• 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
• Current runtime is a Java based interpreter for mid level IR
– Will be compiled via LLVM to native code
7/21/2018 40

41. Ongoing work
• Concurrency management with STM, uniqueness types
• Workflow related
– Forward recoverability
– Compensation
– Checkpoint and restart
• Docker / Kubernetes compositions
• Generic types
• Internationalizing the grammar
• Implementation
– Native compilation via LLVM
– Also WebASM
7/21/2018 41

42. Summary
• Ballerina is an attempt to build 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
7/21/2018 42