< Agenda />
// John De Goes
Keynote: The Last Hope for Scala’s Infinity War
Java, the heavyweight champion of the JVM, has easily defeated attacks from newer programming languages by appropriating features like lambdas, streaming pipelines, and optional types from more capable languages. Kotlin continues its meteoric rise as a better Java, gaining traction from its exploding Android development community, and Eta has given the world its first taste of true Haskell-level programming on the JVM. Scala’s popularity, on the other hand, is starting to decline, driven by long compile times, non-essential complexity in the language, binary and source compatibility problems, the looming threat of obsolesce that is Dotty, brain drain to the Rust and Haskell communities, and fractures in the Scala community that are driven by political agendas and personal grudges.
In this keynote, John A. De Goes, a decade-long Scala user and contributor, presents his unfiltered take on the state of Scala, a raw and bleeding examination of everything that is good and bad with the language, tooling, and community. Extremely grateful that Scala has brought the power of functional programming to many companies, John thinks that despite declining popularity and threats from every direction, there is still hope for the future of Scala. Hope that Scala will power a new generation of businesses who want to leverage the JVM ecosystem to build principled software that is easier to reason about, easier to compose, easier to test, and easier to change.
John has foreseen many permutations of Scala’s future, and while most do not end well for Scala, John thinks there is one possible future that will lead to strong, vibrant, and growing adoption of the language in new and existing domains. Join John in this keynote to learn about this future, and what we must sacrifice to obtain it.
This talk is about a journey: from imperative code to purely functional one. It starts with a program written in imperative style. Its weak spots can be quickly recognized: lack of robustness, testability, and maintainability. We seek our salvation in the functional paradigm, but the road to enlightenment has many dangerous and deceivable dead-ends.
The quest has a happy ending, as we reach code that is performant, testable, readable and maintainable. Keep in mind however that knowledge comes from experience. As once someone wise said, "It's the not the Destination, it's the Journey."
Though it is not a live coding session, it will sure feel like it. The code is written in Scala, parental guidance is advised.
// Paweł Szulc
A roadtrip with monads: from MTL, through tagless, to BIO
Thinking Less with Scala
After 10 years of Object Orientated Java, 2 years of Functional Programming in Scala was enough to convince me that I could never switch back. But why? The answer is simple: Functional Scala lets you think less. It reduces the number of moving parts you need to hold in your head, lets you stay focussed and saves your mental stack from overflowing.
In this talk I'll show you how to stop treating Scala as a better Java and start exploring the world of Functional Programming. I'll use code examples to demonstrate a four step path that'll let you ease yourself into the world of Functional Programming while continuing to deliver production quality code.
With each step we'll learn a new technique, and understand how it leaves you with less to think about: Hopefully this talk will convince you that Functional Scala leads to code that's easier to hold in your head, and leave you excited about learning a new paradigm.
// Daniel Sivan
// Eric Torreborre
What Haskell taught us when we were not looking
Haskell, the pure and lazy functional programming language, has now been around for more than 25 years. It had a profound influence on many other programming languages on the JVM: Scala, Clojure, Java and elsewhere: Purescript, Swift, Go (just kidding, not Go :-)). In this talk you will discover which Haskell constructs have made it to mainstream programming languages and change the way you program today. You will understand why Haskell is actually a simpler language than Scala for functional programming but also how Haskell could benefit from Scala. Warning: after this talk you might be tempted to try the real thing!
About Time: Event-time Stream Processing with Akka Streams
Starting from versatile reactive programming libraries like Akka Streams, and growing up to high-footprint streaming data platforms such as Spark and Flink, data streaming has become an important idiom occupying multiple niches. What differentiates data streaming platforms from comparatively simple libraries? This talk focuses on one specific aspect: time windowing, and the notion of time.
Riskified aggregates large amounts of behavioral data. The kind of stream processing we perform relies on time windowing: incoming event data is partitioned according to bound timeframes.
Time windowing, and the notion of time used, are a key difference between platforms and libraries—platforms offer a robust approach to time windowing based on event-provided timestamps, yielding deterministic results regardless of events arrival time or order; streaming libraries generally just check the local clock.
Our solution brings the notion of event-time to Akka Streams. During the talk I will describe the concepts needed for enabling event-time processing, along with simple building blocks for implementation.
// Nadav Wiener
Streaming Libraries Shootout
Most modern server development stacks include a local streaming library.
Such libraries greatly simplify handling the load and concurrency of incoming requests by leveraging tools such as throttling, fan out and back pressure control.
In this talk I will compare two of the most popular streaming libraries in Scala: Akka Streams and Monix.
Akka Streams is a library built on top of actors, and integrates seamlessly with Akka Http. As such it is more likely to be used by people already using Akka as a framework for their service. Its philosophy is of providing a toolkit for constructing building blocks, from which more complex streams can be built.
Monix is a library that implements the Reactive Streams API, and exposes a collection like interface through its Observable and Task types. Its streams are more opaque, and also simpler to use.
While the projects differ somewhat in goals and size, a comparison is enlightening as to the tradeoffs made by the library authors: what’s missing in each library, and how involved is adding the missing functionality, and when should you use each.
// Gideon Caller
Scala Parser Combinators - The Easier Way to Create an External DSL
In certain domains, offering domain specific languages (DSLs) to our users can prove to be very useful and offer productivity gains, while at the same time allowing the application to evolve robustly.
This can range from configurations of our application, to offering more complicated customization, depending on the domain.
Scala (a Scalable language) is famous for being friendly to creating internal DSLs with its extensive syntactical abilities.
This approach is, however, limited in the syntax it can offer to users.
It is also usually geared towards cases where the DSL needs to gel with Scala itself and therefore more developer-oriented.
Developing an external DSL - one that requires parsing of the text - is usually more cumbersome to write, even with existing popular tools.
In this talk, we'll examine a concrete use case for such a DSL that was used to greatly simplify an existing complicated XML-based customization into a simple DSL.
We'll examine one possible implementation of it using Scala parser-combinators, and how it can integrated with a complete application.
// Lior Schejter
Scala vs. Kotlin, friend or foe?
In this talk I will compare Scala and Kotlin, to show where each language shines and what are differences and when/where I think each should be used.
// Ohad Shai
There comes a time in every Scala developer’s life when they decide to stop writing Java code using Scala syntax. After that, you wonder what’s next. One of the first stops is a functional programming library like Cats or Scalaz.
The problem is that there’s a big gap between learning about functional concepts like Monoids and Monads, and actually using them in production.
I will present several use cases we encountered, explain the problems they incorporate, and show how we used the Cats type classes to solve them.
The talk will highlight how constraining your types in terms of type classes helps building cleaner, more generic and more testable code.
// Ron Aharoni
// Noam Almog
Integration testing of REST services using Akka Http
Testing REST services is hard, setting up environment, executing multiple remote calls, matching results on various encodings and formats and handling tests flakiness while trying to retain an easy to maintain and understandable code base. In this talk I will present how we designed our framework using akka http to handle many of those aspects. Through the design you will gain a glimpse of how we test and maintain over 200 microservices in production.
Building an Immune System in Scala
At Outbrain, we take special pride in our ability to deliver new features to production and doing so with the confidence that only reliable tests can give you.
In order to do it at scale we have built a set of tools, practices, guidelines and culture - we call it our Immune system. In this talk I will describe how we leveraged Scala to build the immune system.
// Anatoly Rabinovich
// Hugh McKee
Safe Passage: Messaging in Microservice Environments
Building a microservice system is fun. Running a microservice system in production is, well, it can be fun, but it can also be challenging. It is one thing to build a microservice system that works well when everything is up and running. It is entirely another thing to create a microservice system that can withstand the exciting array of failures that happen in a distributed network environment. In this talk, you will learn about messaging strategies for microservice systems. What are the significant considerations of synchronous versus asynchronous messaging? When should you use messaging strategies such as maybe-once or at-least-once messaging? Is it possible to do exactly-once messaging? Learn how to build microservice systems that treat failure as an architectural feature, not as an afterthought.
This presentation explores the various strategies used for messaging in a distributed microservice systems environment. We explore the pros and cons of synchronous and asynchronous messaging. We also look at the advantages and disadvantages of the message push and pull message delivery approaches.
Traversals and Scans and CQRS, oh my!
Command/Query responsibility separation and event sourcing are two great patterns for structuring microservices. They are a natural fit for architectures based around Kafka and Streams, and help us achieve immutability and replaybility for our data. However, it's not always clear *how* you should create a CQRS-based application, and where do all the moving parts fit. In this talk, I will show how implementing CQRS and ES in a purely functional manner. We'll see how doing this is nothing more than activating the data types and type classes already written for us: we'll use traversable functors and the State and Writer monads to elegantly construct the components that we need. We'll also touch the pitfalls here and how to integrate these components with a streaming library such as Akka Streams.
// Itamar Ravid
// Milda Glebauskaitė
Writing tests when the code is already there: Golden Master technique
Inheriting someone else’s code is scary. It might be ugly, unreadable and the intentions are not always clear. Especially if there are no tests. How to deal with it? Characterization tests come to the rescue.
There is no doubt, that test coverage brings safety when refactoring or adding new features to code. However, legacy code tend to be untestable and often we’re stuck in a vicious circle were to test, we must refactor, and to refactor, we have to write tests. The purpose of characterization test known as Golden Master is to minimize the refactoring and maximize the safety in these situations.
In this session we will learn when and how to apply Golden Master and try to implement it ourselves.
// Matan Safriel
Clojure Introduction for Scala Devs
Clojure is a well established contender on the JVM, sporting many interesting core features like amazing concurrency idioms, and like Scala it is functional, immutable, and makes calls to Java objects and libraries first class. But to a Java or Scala developer it may appear at first sight entirely outwordly.
This talk will overview the language in a way conducive to the typical Scala dev, linger on its really special concurrency idioms, and crisply juxtapose it to Scala in all core aspects, in a pragmatic memorable way. Hopefully it will make you rethink what you like in a programming language, and leave you with a pragmatic view of the downsides so as to avoid the hype curve. Beware that clojure is also a lisp and is a dynamic language.
// Luka Jacobowitz
Principled error handling - Beyond MonadError
Error handling is a tricky part of every developer's life.
We've come a long way from exceptions and try-catch, but in certain situations, we're still barely scratching the surface.
In this talk we'll see how abstractions like standard MonadError in Scala and Haskell aren't enough to handle errors in a principled matter.
Instead, we will look at different new abstractions that encode error handling into the type system to give us certain guarantees, like signaling that no errors can occur after having handled all previous errors.
This comes in handy, especially when dealing with effectful computations that might fail. Come see this talk to find out what principled error handling can do for you.
SMAC - Scala MAven Cross version in a java world
Scala is not backward compatible When considering compatibility, we need to consider both source compatibility and binary compatibility. Scala does tend to be source backward compatible, so you can rebuild your jar under a newer version, but it is not binary backward compatible, so you can't use a jar built with an old version with code from a new version. The life could be easier if your primary build tool natively supports scala cross version like sbt or gradle. But what if your company’s primary build tool is maven? Things start to be much more complicated…
There are several proposed solutions for that, but none of them simple and elegant. In this talk, we are going to present our solution to this problem.
For that, we will reference two primary use-cases: - Running and building spark jobs for different Scala and cluster versions - Building and gradually upgrading microservices
// Yulia Stolin