Talk I gave at BallerinaCon co-located at KubeCon US in Seattle in December 2018

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