The Erlang Ecosystem Foundation's goal is to grow and support a diverse community, encouraging the continued development of technologies and open source projects based on and around Erlang, Elixir, other BEAM languages and their runtime. In this talk, we will discuss some of the challenges, success stories and plans of some of the most active work groups, let you know how you can get involved, contribute and help influence. 

 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.

We'll go over important updates and announcements. If you've any questions about the conference, like how do I get the videos, etc. this session will help you answer all those questions. So don't miss it.

Welcome Address and Functional Conf Overview. Here you will get al the important details you need about the conference. So don't miss it.

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.

When I say "Multiplayer online game development in Clojure" 2 questions probably pop right up : WHY? HOW?
Why? because you can do it in under 100 lines of code, and it is pure FUN.
How? Well that's exactly what we'll talk about in this session.
I will present a simple MOG written in Clojure and go through each line of code - so you'll understand how you can do that yourself, even if you've never written a single line of Clojure before.
Whether you’re a real Clojurian at heart or just interested in hearing a talk about Clojure from a sworn star wars fan - this talk is for you :)

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.

Programming language may share much in common, but each language has its own particular syntactic and semantic features. For example, a function application in Haskell can be an operator section, while in Erlang it can be an application of the apply function. This talk presents generic, language-independent refactoring schemes that are realised in each language by a particular set of rewrites, and is illustrated by examples from Erlang, Haskell and OCaml.

We each follow similar paths into the forest of functional programming. Some languages are better suited than others but we all hit a wall on our way to mastering monads. In this talk, I'll use examples from the Swift programming language to trace our understanding from types  that feel like containers such as Array and Optional to types that definitely don’t such as Reader and State Monads. We’ll learn to perform many magic tricks along the way.

In this presentation, we will see coding problems, similar to those which can be found at https://github.com/system-f/fp-course/ using the Haskell programming language.

Solving problems such as these can be daunting for many reasons and especially for beginners. A common stumbling block to these types of problems is coming up against unfamiliar problem-solving methods. For example, everyone knows how to add up the numbers in a list with a for-loop. This is a well-understood method of solving this particular coding problem.

And then you hear the functional programmers, "just use the types" and "well you just do the only obvious thing to solve it." While true, this is not particularly helpful to someone who is not already fluent with this approach to problem-solving.

You may have heard of using type-holes to solve coding problems. We'll be using type-holes, and a few other techniques, with the Haskell programming language to live-solve coding problems. We will solve both trivial and not-so-trivial problems while "thinking out aloud." Feel free to follow along! You'll just need Glasgow Haskell Compiler (GHC) and a text editor installed.

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.

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.