Loops are among the most critical programming constructs. These features shape core ideas about programming in the Erlang ecosystem; from how languages work to how programming features interact with other code and the outside world. How systems scale and are resilient. They are also metaphors for the way we think, build things, and grow. In Erlang and Elixir, loops define servers that form reliable, fault tolerant and scalable services. This keynote will explore Elixir and Erlang's approach to concurrency with a nautical adventure called the Great Loop.

This talk dives into the origins of functional programming, going all the way back to where the term was first introduced, to see how it evolved over time into our modern understanding of what FP essentially involves.

Scala 3 was introduced last year. It introduced significant changes to the language, many of which were motivated by the lessons learned from the past 15 or so years of actual use in many open-source and commercial applications.

I'll explore these lessons and how Scala 3 addresses them. Many revolve around the pros and cons of implicits. Also, changes to the type system make it more "regular", robust, and expressive. Finally, the new, optional, and controversial "Python-like" syntax promotes even more brevity. It also acknowledges how influential and pervasive Python has become across our industry.

But there are many practical areas where future work is required, many of which are larger than the scope of Scala itself. We still live in "dependency hell". We still use too many obsolete idioms that hide accidental complexity, rather than forcing us to fix it. What should we do about these issues? 

At HCA Healthcare, we built Waterpark– a continuously available, geographically distributed, high velocity Enterprise Integration Platform. We built it from scratch in Elixir. Elixir and the ErlangVM are very powerful tools. Need to model millions of things? No problem. Need processes to self-heal when things break? No problem. Need to model millions of things that self heal on computers scattered across a continent? Hmmm… for that you’ve got some work to do, but in Elixir that work is very doable and fun. In this nuts-and-bolts session, we will discuss the distributed computing bits that are in-the-box with Elixir and what is missing. We will cover the missing bits that we built and “why”. Topics include: hashing functions, distributed process registries, the mailroom pattern, server topology, leader election, consensus, actor replication and recovery, and hot code loading. 

With polymorphic functions you can often tell how they are implemented by looking at their outputs. The more polymorphic the function, the more you can tell about its internal workings. Lenses, as well as more general optics, have convenient polymorphic implementations in terms of functors and profunctors. But under layers of abstractions they are hiding some simple truths. We are going to get to the bottom of this conspiracy.

Don't ask what you can do for your testing library, ask what it can do for you! So what can it do? It turns out that much more than displaying a nice green and red report. What if we make the library generate the test data? And while we're at it, maybe it could also think of the edge cases for which our code is wrong? Oh, and when it finds them, it should simplify them a bit before returning to us, so that we can quickly identify the root cause of the problem. And repeat that a thousand times, just to be sure. Sounds good? That's exactly what property-based testing has to offer. I'll show how to get started with this kind of testing, using jqwik (https://jqwik.net/) as an example. But isn't it all too good to be true, surely there's some fine print? Of course there is. I'll cover that as well.

Web services are typically stateless entities, that need to operate at scale at large. Functional paradigm can be used to model these web services work and offer several benefits like scalability, productivity, and correctness. This talk describes how to implement Event-Driven Microservices in functional programming languages with examples in F#.

Immutability allows infinite scalability as it eliminates the need to worry about a mutex, a lock, or a race. As functional code is much more terse compared to object-oriented code, it provides productivity benefits. Its strict typing makes writing correct code easy as mismatches of types are caught at compile time.

The objective of the talk is to show how to create a scalable & highly distributed web service in F#, and demonstrate how various characteristics of functional paradigm captures the behavior of such services architecture very naturally.

Some people even say names don't matter. While it is widely held that good naming is one of the most important aspects of programming, is there such a thing as an objectively good name?

As part of a discussion of the philosophy of programming, we'll look at what are the real aims of naming things well, and what considerations we should have in mind when discussing them. We'll have a look at alternatives and what they bring that names do not.

You may be familiar with what map, filter, and reduce do. But have you ever heard how these functions sound?

The Alda language is centered around the idea that music can be represented as data. alda-clj is a Clojure library that maps Clojure data structures to the music theory concepts in the Alda language, including notes and chords. The library serves as an interface that takes Clojure code as input and produces music as output.

In addition to the basic functions that you will find in the standard libraries of most functional programming languages, Clojure's standard library offers a wealth of interesting and useful functions that facilitate working with immutable data. In this talk, we will explore the Clojure standard library by applying interesting functions like cycle, mapcat, partition and reductions to transform data that represents music. Using the alda-clj library, we will not only see the result of each function call, we will also hear the results and observe how they can help us understand how each function works.

Have you ever experienced vendor lock-in from your observability tooling? Don't you wish you could instrument your code once and send telemetry data to multiple vendors to see what their platforms have to offer before signing a contract and investing a lot of engineering time?

The future is now, with OpenTelemetry!

OpenTelemetry has finally reached general availability, with the Erlang and Elixir library leading the way as one of the first official implementations to be compliant with this new industry specification. Now is the time to start thinking about how to get your services instrumented using this exciting new vendor-neutral instrumentation.

This talk will quickly cover the basics you need to know to get started and send data to both open-source tooling and vendor platforms, so that you can get the observability you need, without being locked into a specific vendor's instrumentation library!

Quantum Computing is all the rage these days, but, as an emerging technology, it's difficult to find practical applications right away. One area which allows us to invest in a quantum future is to use quantum- and nature- inspired optimization algorithms, which can run on classical computing infrastructure today and leverage quantum hardware when it is available.

In this talk, I'd like to give a short overview of the state of the art in quantum computing, and introduce two widely used optimization algorithms made better in F# with functional principles.

Fable is an F# to JS compiler that has been successfully used in production by thousands of developers for more than 5 years. Thanks to steady improvements and a great community and ecosystem, including the SAFE stack, the Elmish architecture and the Feliz React API, it has become one of the best options to write robust, succinct and performant web applications nowadays.

Fable was originally designed to integrate F# with the JS ecosystem instead of trying it to hide it. With this same philosophy, the Fable team is working now to target other languages beyond .NET and JS. There are already working prototypes to compile F# into Php, Python and Rust code, and we expect to release a beta in the upcoming months. Let's see how Fable 4 will further empower F# and functional programmers!

Beginning functional and APL programmers often express confusion about how to structure large software projects or larger pieces of code. Both APL and FP have a tendency to highlight their low-level features and de-emphasize system architecture patterns. This can leave programmers with a strong sense of how to write a set of small functions, but with less confidence or skill in designing, recognizing, and implementing more cohesive implicit system architectures that hold these lower level functions together. System architectures serve as a method for constraining the overall design of a system to give direction and focus to lower level implementation requirements. Especially in APL, where system architecture is often best implemented implicitly, it behooves the programmer to understand the ramifications of architecture and to implement them in their own systems. This talk unpacks a number of these "architecture level" questions within the framework of the APL programming language by exploring the same topic through 3 different architectural approaches, each of which has a very distinct flavor, presentation, and impact on the resulting source code. Particular attention is paid to the question of domain-specific languages, their design, and how they can interact with APL as tools for architectural exploration and guidance in APL source trees. 

Satisfiability modulo theories (SMT) solvers are extremely powerful tools that are indispensable in a number of applications of functional programming from mathematical analysis and optimization to computer security to program verification. SMT solvers allow you to determine if certain logical and mathematical formulas are satisfiable or (just as importantly) unsatisfiable in the context of theories like real arithmetic or set theory, and can provide definitive answers to commonly encountered programming problems involving logic, arithmetic, equations, and constraints.

Z3 is one of the most popular SMT solvers available today with APIs available for many different programming languages. Although Z3 is most commonly used from Python, functional languages like F# provide powerful metaprogramming facilities that make it very easy to translate F# code and expressions to Z3 expressions without the need for custom types or operators.

This presentation describes how the Z3 solver can be used from F# via quotations to quickly and easily solve common programming problems from Boolean formula satisfiability to arithmetic expression equality to linear programming to verifying fragments of source code.

Typescript has gained a lot of traction with majority of javascript frameworks adopting it and gaining the power of static types.

Given the Typescript types are a language themselves and they are Turing complete, lets put our type flavoured favourite language of the web to test - for fun & profit.

With the advent of fp-ts, typescript's boundary to statically type FP algebras like Functor, Monoid & Monad are just a import away!.

But why restrict ourselves when we can achieve more with almost "Dependent types" in typescript - Like solving logical puzzles to proving properties of the program (like type level regex check, indexed list & matrices etc) for correctness.

Many Java developers believe that FP arrived in Java 8, with the addition of first-class lambda expressions and the Streams API. But is this really true? In this talk, Ben Evans will talk about what FP really is, examine whether Java can really be said to be FP or not - and consider whether things have improved with more recent versions, as well as some possibilities of how we could have done things differently (in another world).

“A language that doesn't affect the way you think about programming, is not worth knowing.” ― Alan Perlis, in “Epigrams in Programming”

Following Alan Perlis's words, this talk will show why APL is a language worth knowing. In other words, I will devote the talk to showcasing characteristics of APL that are likely to, on the one hand, influence the way you use other programming languages, and, on the other hand, understand concepts of computer science.

By listening to this talk, I hope to convince you that learning a language that is radically different from all the other languages you know isn't harmful. Learning a language that is radically different from all other languages you know won't scatter your knowledge or spread your brain too thin. In fact, learning a language that is radically different from all other languages you know will cement your programming  knowledge, helping you build bridges between topics you didn't even know were connected.

To drive my point home, we take a closer look at two characteristics of APL: the fact that Boolean values are represented by the integers 0 and 1, and the fact that APL is an array-oriented language. In studying these two things, we draw connections to the traditional if statement and to list comprehensions, deepening our understanding of those.

What do you do with a multi-step function with different kinds of user input that may be required at different steps? 

I'm using Elm to build a game client for Codex, a complex strategy board game by David Sirlin with lots of interesting side effects in the game design. The pure functional programming of Elm is very powerful for managing these side effects, but how should I handle when there are many different kinds of user input required to complete the behaviour of a single feature?

There’s a “railway oriented programming” metaphor to understand how to handle multiple-steps of errors. I’ll extend this metaphor – with stations – to show how to make what looks like a complex functional problem into a simple pattern of abstraction.

Some familiarity with functional programming idioms is recommended, though the examples themselves are easy to follow. Attendees will walk away seeing functional programming applied in a fresh way, perhaps opening their mind to alternative perspectives to approach the complicated problems in their projects.

OCaml - a functional programming language from the ML family, recently celebrated its 25th year. For a language to be around for that long is an achievement in itself. Furthermore, people are actively working on adding exciting features to the language and its ecosystem.

Thanks to efforts from various developers and maintainers, the OCaml developer platform has come a long way and continues to evolve at a rapid phase. My talk will cover all the existing tooling that makes a OCaml developer's life easy.

The talk will demonstrate end-to-end state-of-the-art developer tooling, right from installing a OCaml compiler, using VSCode and vscode-ocaml-platform which provides IDE like features, to publishing a library and its documentation.