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.

Languages and ecosystems are more than simply syntax; they’re ways of thinking. They have features, idioms, and community standards that drive us towards certain ways of doing things. Erlang is over 30 years old, and has a very mature way of doing things. Elixir came on the scene, bringing with it some new ideas from other ecosystems. We’re seeing even more of this with BEAM languages from LFE to Alpaca to Erlog.

Ideas come in and out of fashion. Some of them are lost and aren’t given a chance again. But as technology continues to evolve, perhaps there’s space for what’s old to be made new again! This talk will explore a few idea lost to time that perhaps have their chance to shine again. It asks what could languages would look like if history had gone slightly differently, and what depths we can plumb for the next 30 years and 50 languages on the BEAM.

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.

Haskell (and the kind of Statically Typed Functional Programming that it promotes) is notoriously hard to learn. I have struggled with the learning curve. I have seen others struggle with it. And I have seen developers struggling to wield the language effectively even after months of learning.

But it is not necessary to jump into the weird world of Monad, Monoid, and Endofunctors. There are neighbouring languages that can be immediately put to good use and introduce some of the Typed FP concepts more gradually.

We'll talk about one of them - Dhall: A Typed FP language specifically for configuration management.

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.

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 :)

Robots are exciting. Lots of progress in robotics in terms of research, tools, and state-of-the-art libraries that we see in modern robots became possible due to Robot Operating System (ROS). It is the most popular open-source robotics middleware that enables roboticists from both academia and industry to collaborate and relatively easy get robots up and running. However, ROS is neither scalable, nor fault-tolerant, and these are areas in which the Erlang programming language has lots to offer.

In this talk, we'll introduce ROSiE (Robot Operating System integrating Erlang) that merges togetherness and state-of-the-art of the open-source robotics world with expertise in scalability and fault-tolerance of Erlang. We'll talk about our vision, finds, and progress so far

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.

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.