2018 12-kube con-ballerinacon
Download as PPTX, PDF3 likes1,034 views
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.
![Hello, World service
$ ballerina run helloservice.bal
Initiating service(s) in 'helloservice.bal'
[ballerina/http] started HTTP/WS endpoint 0.0.0.0:9090](https://image.slidesharecdn.com/2018-12-kubecon-ballerinacon-181211161635/85/2018-12-kube-con-ballerinacon-10-320.jpg)
![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](https://image.slidesharecdn.com/2018-12-kubecon-ballerinacon-181211161635/85/2018-12-kube-con-ballerinacon-19-320.jpg)
![json
• Union of
• string | boolean | int | float | decimal | map<json> | json[] | ()](https://image.slidesharecdn.com/2018-12-kubecon-ballerinacon-181211161635/85/2018-12-kube-con-ballerinacon-21-320.jpg)
2018 12-kube con-ballerinacon
- 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
- 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
- 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
- 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