Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

2018 12-kube con-ballerinacon

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

  • Be the first to comment

2018 12-kube con-ballerinacon

  1. 1. Ballerina: A modern programming language focused on integration Sanjiva Weerawarana, Ph.D. Lead Ballerina Founder & Chairman, WSO2
  2. 2. Overview • Motivation • Key differences • Type system • Errors • Concurrency • Networking • And more • Beyond the language • Standard library, developer tools, testing, documentation, observability
  3. 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. 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. 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. 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. 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. 8. Hello, World main % ballerina run hello.bal KubeCon
  9. 9. Hello, World main
  10. 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. 11. Type system
  12. 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. 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. 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. 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. 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. 17. Other type descriptors • Singleton • Union • Optional • any • anydata • byte • json
  18. 18. any • Describes type consisting of all values except error values • Thus, any|error is a type descriptor for all values
  19. 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. 20. byte • Union of 0 | 1 | .. | 255
  21. 21. json • Union of • string | boolean | int | float | decimal | map<json> | json[] | ()
  22. 22. Errors
  23. 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. 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. 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. 26. Concurrency
  27. 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. 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. 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. 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. 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. 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. 33. Networking
  34. 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. 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. 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. 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. 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. 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. 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. 41. And more …
  42. 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. 43. Beyond the language
  44. 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. 45. Beyond code • Editing & debugging • VSCode and IntelliJ plugins • Testing framework • Observability: metrics, tracing, logging • Documentation generation • Modularity, dependencies, versions, building & sharing
  46. 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. 47. Compiler architecture
  48. 48. Conclusion
  49. 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. 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. 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

×