There’s an amazing lineup of functional programming awesomeness at NDC Oslo this year. The track will be in Room 2 all week. Pick a nice seat and get cozy! I will update this page with links to session recordings as they are posted.


Here’s a Twitter list of the FP-Track speakers. We would all love hear from you. Your pictures, quotes, feedback, and questions with the “#ndcoslo” hashtag are much appreciated.

The Agenda

Day 1 (Wednesday, June 17, 2015)


Keynote by Bruce Schneier - “Data and Goliath: The Hidden Battles to Collect Your Data and Control Your World”


  • Bryan Hunter “Lean and Functional Programming” - (Room 2)

“Companies adopt Lean because it is a proven path to improving delivery times, reducing cost, and improving quality. A company that writes software cannot truly embrace Lean without also embracing functional programming. Why? Lean is about building quality into the process. Lean is a systemic method for reducing waste, overburden, and inconsistency. With OO, many forms of waste, overburden, and inconsistency are unavoidable. A defect early in the process always results in a defect in the product later in the process, and OO itself is a defective process. In this session we will go from the origins of both Lean and FP and see how specific FP concepts (examples in F#, Elixir) map onto Lean principles. We will also discuss why some companies fail at Lean and FP.”


  • Yan Cui “A tour of the language landscape” - (Room 2)

“There seems to be a new programming language every week, and for us busy developers we just don’t have the time to keep up with them. But have you wondered what we might haved missed out on whilst we’re busy working in our language of choice?Having spent time with numerous programming languages the past few years I have learnt something new from each. In this talk, we will go on a whirlwind tour of the interesting concepts and ideas I have encountered, from F#’s type providers and Rust’s borrowed pointers, to Elm’s signals and Idris’s dependent types to name a few.”


  • Scott Wlaschin “Enterprise Tic-Tac-Toe - a Functional Approach” - (Room 2)

“Follow along as I ridiculously over-engineer a simple game to demonstrate how functional programming can be used to create a real-world “enterprise-ready” application.

Topics covered include: encoding business rules into types, data hiding with parametric polymorphism, using functions for capability-based security, exposing a REST API with HATEAOS, the functional approach to logging, actors, scalability and more.”


Whether you’re a fan of static typing or functional style of programming, a language that stands far apart and serves as a guiding force to a lot of different languages in these areas is Haskell. Learning about Haskell gives a very different perspective on typing and about functional programming. Knowing how Haskell does these influences the way we think and design our applications in different languages. Whether you program in C#, F#, or any of the other languages, come to this talk to get influenced by Haskell’s way of thinking and coding.


  • Andrea Magnorsky “Computation expression in context : a history of the otter king” - (Room 2)

I heard that computation expressions are kind of like monads. I heard that monads are like burritos or space suits, and that they are pretty much magical. I also heard that they are monoids in the category of endofunctors…

As a writer of code that all sounds awesome, and I want to know and understand (and I’m sure you do too) what those terms actually mean, and most importantly why we should care about them. What are their practical uses? So, in this talk we are going to attempt to do just that. Failure is possible, but the attempt is valuable. It’s a lot to chew so make sure you had your tea/coffee.


The F# type system is both stronger and more flexible than the type system in e.g. C#. You can use this to your advantage to rapidly evolve a prototype.

In this talk you’ll see an example of how to evolve a Finite State Machine that solves a real problem, using the F# type system as a driver.

Day 2 (Thursday, June 18, 2015)


  • José Valim “Idioms for building distributed fault-tolerant applications w/ Elixir” - (Room 2)

This talk will introduce developers to Elixir and the underlying Erlang VM and show how they introduce a completely new vocabulary which shapes how developers design and build concurrent, distributed and fault-tolerant applications. The end of the talk will focus on Elixir and include some live coding.

[Expectations: Introduce Elixir, its ecosystem and design goals within the Erlang Virtual Machine]


Storing history rather than current state, Event Sourcing is a radical technique to implement efficiently Domain Driven Design. But many stop before even trying, convinced of the difficulty to implement it. A short F# sample shows how to implement Event Sourcing. The functional approach leads to a simple, clear and production ready solution, and uncluttered domain code ! No prior knowledge of F# required…


  • Chris McCord “Phoenix - a framework for the modern web” - (Room 2)

Phoenix is an Elixir web framework for building productive, reliable applications with the performance to take on the modern computing world. Together, we’ll review what makes Phoenix great and how it uses Elixir to optimize code for performance – without sacrificing programmer productivity. Along the way, we’ll see neat features like live-reload and generators and how Phoenix’s realtime layer takes on the modern web.


In psychology, the need for Clojure “… is usually provoked after experiencing an emotional conclusion to a difficult life event, such as the breakdown of a close interpersonal relationship [with an unreliable concurrent program, personal note]…” [1]. “A person with a high need for closure prefers order and predictability and is decisive […]” [2].

My path to Clojure started with trauma, then Java Concurrency in Practice, (then almost Scala), then hope and then, finally, Clojure in production at Xamarin Test Cloud. When I first heard of Clojure back in 2008, it was love at first sight [3].

This talk will be a friendly, practical introduction to Clojure for those who are new and curious. We’ll look at the cornerstones of Clojure, as well as look at practical examples drawn from our use of Clojure in building Xamarin Test Cloud [4], a cloud services that provides access to more than a thousand mobile devices for the purpose of mobile quality assurance. Leave inspired to try out Clojure.


I have always said that Event Sourcing is “Functional Data Storage”. In this talk we will try migrating to a idiomatic functional way of looking at Event Sourcing. Come and watch all the code disappear! By the time you leave you will never want an “Event Sourcing Framework (TM)” ever again!


For data exploration and rapid prototyping, the productivity of an interactive scripting environment is hard to beat: simply grab data, run code, and iterate based on immediate feedback. However, that story starts to break down when the data you have to process is big, or the computations expensive. Your local machine becomes the bottleneck, and you are left with a slow and unresponsive environment.

In this talk, we will introduce, an open-source and free engine for scalable cloud programming. Using the MBrace programming model, you can keep working in your beloved familiar scripting environment, and easily execute C# or F# code on a cluster of machines on Azure. We will focus primarily on live demos, from provisioning an Azure cluster with Brisk, to analyzing large datasets in a distributed fashion; in particular, we will discuss how this setup is relevant to data science and machine learning.


  • Torben Hoffman “Using Elixir to get the fun back in Lego Mindstorms” - (Room 2)

Robots are fun. Programming is fun. Programming Lego robots with the visual environment… well, not so fun. This is the starting point for putting Elixir on the Lego Mindstorms EV3. It ought to be fun to do, but my son and I got lost in the visual environment when trying to do advanced things. After having created a simple EV3 library in Elixir the fun started coming back. This talk is about how the EV3 Elixir library works and how to use it to make robot control software that is easy to write and understand. One of the key building blocks in Elixir - as in Erlang - is processes, and we will have a look at how to design things using lots of processes and how that makes things easier to work with. We start from conceptual architecture and end with elegant Elixir programs. As we go along a visual notation that fits the domain will be introduced showing the benefits of having a small semantic gap between domain, architecture and language.

Day 3 (Friday, June 19, 2015)


This talk is for C# programmers who are curious about F#, a multi-paradigm and cross-platform programming language.

In: test driven development, classes and functions

Out: maths, monads and moth-eaten jumpers

Expect plenty of practical examples with live code samples, including interop between C# and F#.


  • Tomas Petricek “End-to-end Functional Web Development” - (Room 2)

One of the myths about F# is that it is only good for complex mathematics. In this talk, I’ll show you that this could not be further from truth. A web server is essentially a function from a request to a response and so functional programming is a perfect fit for it.

In this talk, I’m going to walk through a complete web development story with F#. We’ll start with a script file to test a couple of ideas, wrap the code into a web server and we’ll finish by deploying our system to Azure and Heroku. If you’re curious what this is going to be about, you can check out one of the samples that we’ll build at

You will learn:

  • How to write web applications using the web server
  • How to call REST services using F# Data type providers
  • How functional web server design makes it easier to test your system
  • How to deploy F# web apps to Azure and Heroku with FAKE


  • Irina Guberman “Maximizing throughput on Multicore Systems” - (Room 2)

Erlang is the best language there is for getting the most out of your concurrent system – it was created with multi-core processing in mind! However, to get the best of it we need to understand what our concurrent processes are actually doing and how they’ll play out with our system’s physical limitations, a concept also known as mechanical sympathy. I would like to explore this subject based on my project at Ubiquiti Networks and take a look at an existing tool that could make the task of maximizing throughput on you multicore system easy and fun: the “Jobs” Framework by Ulf Wiger.

  • Explore a business case scenario of a highly concurrent HTTP server requiring high CPU utilization.
  • Explore “Jobs” framework in great detail with code snippets and fun pics. By the end of it anyone can start using it even developers with no Erlang background!
  • And last but not least: Demonstrate that Erlang is a fantastic choice for writing highly concurrent applications! Target audience: Any developer interested in writing concurrent applications.


Elixir macros give programmers the power to write code that writes code. This power eliminates boilerplate, allows Domain Specific Language abstractions, and provides the freedom to extend the language. Leveraging the fact that it can be represented by its own data structures, Elixir can interrogate its own code to peer in for analysis or to add additional functionality. Used appropriately, macros offer effective module composition and code generation techniques, while more liberal use can serve as an outlet for novel insights through experimentation.

Starting from the basics of macros, we’ll explore these ideas from an introductory level through advanced topics and real-world use-cases. Along the way, we’ll see how Elixir uses meta-programming to generate parts of its own standard library. We’ll also examine how macros can be used to save time and share functionality in a fun and productive way.


F# is a language I am passionate about and a language I would like to use on my day job, and for that to be a reality I need you to join me! I want you to join me in the welcoming F# community where you can see a new world open up for you and enabling you to solve problems more efficiently than you do today with C#. F# is not a language that is used only in academia, it is a general purpose language that is growing every day with an awesome community of brilliant people. F# also defines the future of C# in many ways, so if you want to be ahead of the game you should jump on the F# bandwagon today. There are many reasons to learn F# like; a new paradigm will make you a better overall developer, F# will make you write less bugs and you will have more fun at work!

I this presentation I will show you:

  • What the strengths of F# are
  • Why you should start using F#
  • How you get started with F#
  • Don’t hesitate, join the F# movement. The only way to improve is to change!


  • Torben Hoffman “Implementing the logic for a board game in Elixir” - (Room 2)

Board games are fun and good challenges when exploring a new language. The requirements are clear - if only software requirements were as clear - and poses some interesting problems when it comes to implementation of the often quite cunning rules.

Imperative, object-oriented and functional languages all provide their own answers on how to implement board game logic.

Elixir is a concurrency oriented, functional language. This means new ways of solving the problems.

In this talk we will look at how Elixir can be used to implement the logic for the board game classic Acquire. And some of the ideas can even be used for “real-life” problems as well!

Talk objectives: * Show how to break down board game logic in to manageable pieces. * Show how processes and functional programming work together in asoftware design. Target audience: programmers wanting to understand a different way of thinking. the little board gamer inside all of us.

Track Blurb

It is business time for functional programming, and the goal of th track is to help you “make it real” in 2015 by bringing FP into your day job. For many attendees the benefits of F# are within reach, and we have assembled a stunning line-up of F# badasses (including hometown hero Tomas Jansson) who will each demonstrate how moving to F# is a good business decision. Outside of F#, one of the most business relevant (and exciting) stacks is the pairing of Elixir (a modern Erlang VM language) and the web framework Phoenix. We’re delighted to have José Valim (creator of Elixir) and Chris McCord (creator of Phoenix) join in this year’s FP track. Game on!

The other day I received an email from a friend who is coming to Elixir from Ruby. The subject line was “elixir immutability”.

The question

I’m working throughout the tutorial and I cannot understand why the language is immutable AND I can keep re-assigning the different values to the same variable

iex(21)> x = 1
 iex(22)> x = 2
 iex(23)> x

I thought the definition of immutability is that you can’t do that! What gives?

My response

Variables in Elixir are immutable like they are in Erlang. The thing you are seeing that looks like mutation (and drives many Erlangers crazy) is called rebinding (more here). So in your shell example, you didn’t actually change the value that x pointed to. Instead, you created a brand new identifier with the name x that pointed at a different value (2). The old identifier x is no longer available, but its old value (1) remains in memory untouched until it is garbage collected. The following sample uses an anonymous function to show what’s happening a bit more clearly:

iex(1)> x = fn () -> "First one" end
#Function<2.90072148/0 in :erl_eval.expr/5>
iex(2)> z = x
#Function<2.90072148/0 in :erl_eval.expr/5>
iex(3)> x = fn () -> "Second one" end
#Function<2.90072148/0 in :erl_eval.expr/5>
iex(4)> x.()
"Second one"
iex(5)> z.()
"First one"

I’m not a fan of rebinding, but under the hood, Elixir plays by the same rules as Erlang. It may put you at ease to know that the Elixir compiler is taking your x = 1,x = 2 and mapping them to identifiers that do not clash such as x1 = 1 and x2 = 2 before it all goes to byte code.

Elixir’s rebinding doesn’t create any of the shared-mutable-memory concurrency problems of non-functional languages. I suppose José Valim felt the syntactic sugar of rebinding would make people feel more at home if they were coming from OO languages.”

The reply

And that explanation explains it perfectly. If you blog elixir, consider posting that because I didn’t “get it” from googling for it.


Well not quite…

I feel I need to go into why rebinding drives many Erlangers crazy, but first let’s start with how Erlang drives everyone else crazy. Rebinding was introduced in Elixir to avoid an ugly thing that happens in Erlang code when you need to perform a series of operations on some data. For example a dictionary in Erlang…

Eshell V6.3  (abort with ^G)
1> X = dict:new().
{dict, ...
2> X1 = dict:append("A",1,X).
{dict, ...
3> X2 = dict:append("B",2,X1).
{dict, ...
4> X3 = dict:append("C",3,X2).
{dict, ...

Yes, the intermediate variables X,X1,X2,X3 are pretty darn ugly. It’s not just ugly; it’s potentially dangerous. Several times in Erlang, I’ve accidentally passed the wrong intermediate variable to a dict and as a result “lost a step” in the transformation. Unless you make an unfortunate combination of multiple goofs, you will get a compiler warning saying you have “unused variables”. That compiler warning often saves the day. At any rate, everyone agrees this code is ugly.

Now back to Elixir. Elixir’s rebinding allows something more “normal looking” (to a non-FP developer anyway).

iex(1)> x =
iex(2)> x = Dict.put(x, "A", 1)
#HashDict<[{"A", 1}]>
iex(3)> x = Dict.put(x, "B", 2)
#HashDict<[{"A", 1}, {"B", 2}]>
iex(4)> x = Dict.put(x, "C", 3)
#HashDict<[{"A", 1}, {"B", 2}, {"C", 3}]>

There we only have to keep up with one variable x. While not as ugly, this code is still pretty ugly, and there is a better way. Elixir’s lovely pipe-forward operator (|>) produces a much more elegant solution:

iex(1)> x = |>
...(1)> Dict.put("A", 1) |>
...(1)> Dict.put("B", 2) |>
...(1)> Dict.put("C", 3)
#HashDict<[{"A", 1}, {"B", 2}, {"C", 3}]>

The |> says: “take the output of the expression to the left and push it in as the first argument to the expression on the right”. This feels functional; this makes me happy. With the pipe operator, I don’t need/want the ability to rebind x to different values.

The harm for Erlangers

Ok, but where is the actual harm in rebinding? The thing that drives Erlangers crazy is not aesthetics (obviously)…(rimshot)…(cheapshot).

Say we are Harry from the Harry Potter series. Ron Weasley is our buddy, and Voldemort will kill us on sight. We decide to code up a safety charm for our front door. We select Elixir and the ErlangVM because it is functional, declarative, and reliable. Here we go…

iex(1)> friend = "Ron Weasley"
"Ron Weasley"
iex(2)> enemy = "Voldemort"
iex(3)> knocking_at_our_door = "Voldemort"

Yes, Ron is our friend and Voldemort is our enemy, and you-know-who is about to knock at our door. Our case statement should welcome our friend (i.e. “Ron Weasley”) and curse/disarm our enemy (i.e. “Voldemort”).

iex(4)> our_response = case knocking_at_our_door do
...(4)>   friend -> "Come on inside, #{friend}."
...(4)>   enemy -> "Expelliarmus!"
...(4)> end
"Come on inside, Voldemort."

Wait! What the hell just happened?! Voldemort knocked at our door, and we say, “Come on inside, Voldemort.” Let’s check our variables (and our underpants) to see what just happened…

iex(5)> friend
"Ron Weasley"
iex(6)> enemy
iex(7)> knocking_at_our_door
iex(8)> our_response
"Come on inside, Voldemort."

This is crazy. And we are dead. If we had written the following code instead, Harry Potter would have lived.

iex(4)> our_response = case knocking_at_our_door do
...(4)>   ^friend -> "Come on inside, #{friend}."
...(4)>   ^enemy -> "Expelliarmus!"
...(4)> end

See the difference? Notice the ^friend versus friend and ^enemy versus enemy. The hat ^ says “use the last pinned value of this variable.” Without the ^ the variable friend wasn’t used as a guarding, declarative pattern match; instead it was used as a short-lived re-bound variable that held whatever was passed in. That first clause would always match no matter what was passed in, and as soon as the case statement fell out of scope the only evidence that friend was ever equal to Voldemort is our_response. That is subtle; that is dark magic. It is easy (especially for Erlangers who expect a match) to miss it. This will cause problems, and the upside is hard to see.

Another question: if we write this as a module, will the compiler save us with a helpful warning? Answer: maybe, or maybe not.

defmodule KnockKnock do 
  def who_is_there do
    friend = "Ron Weasley"
    enemy = "Voldemort"
    knocking_at_our_door = "Voldemort"

    our_response = case knocking_at_our_door do
      friend -> "Come on inside, #{friend}."
      enemy -> "Expelliarmus!"


…and we compile

iex(1)> c "knock_knock.ex"
knock_knock.ex:9: warning: variable enemy is unused

Hmm… Mixed bag. There is no warning about friend because we (pure-dumb-bad-luck) happened to use the value in our response. We do get a compiler warning on line:9 because enemy is not used in that clause (pure-dumb-good-luck). That might have been enough to clue us in to the bug. If not, when we run…

iex(2)> KnockKnock.who_is_there
{"Ron Weasley", "Voldemort", "Voldemort", "Come on inside, Voldemort."}

Knock, knock. Who’s there? You know. You-know-who?


Identifier rebinding is not harmful in the same way that mutable variables are harmful. It’s not going to jack up your parallel work. Rebinding does create a potential pitfall though, and it adds a diligence requirement (always a bad thing) when using pattern matching.

This is an ugly wart on a beautiful language. Fortunately, there is a solution that is well proven, and it doesn’t require Elixir to beak its v1.0 contracts. In Erlang, if you write a case in which a pattern will never match you get a warning

Warning: this clause cannot match because a previous clause at line 11
always matches

If Elixir were to do the same everyone wins (except Voldemort).

Functional Track talks from NDC London 2014


Here’s a Twitter list of the NDC London 2014 FP-Track speakers.


Each session was recorded. Click on the session links for video.

Wednesday 2014-12-3

Thursday 2014-12-4

Friday 2014-12-5

Pretty excited about yesterday’s release of Erlang/OTP 17.0. You can read more about why this release is important from Joe Armstrong’s February 1 post: “Big Changes to Erlang“. The release of Erlang/OTP 17 is important to the v1.0 release of Elixir as well: “Milestones for 1.0“.

Getting it:

The good folks at Erlang Solutions publish and maintain a library of prebuilt Erlang packages for many platforms here.

If you are on Linux or Mac many folks use a handy tool named Kerl to build and switch between multiple releases of Erlang. Get started here:

If you are on Windows you’ve got it easy. Go to the’s download page (here) and download the 32-bit or 64-bit OTP 17.0 Windows Binary File. It runs as a standard Windows installer, and it works great. All dependencies are pulled in for you including wxWidgets which is used with the graphical tools Debugger and Observer.

Finally, if you are on Ubuntu and want to see how to build from source (and get the required dependencies) I have a Gist that will help you “Build Erlang 17.0 on a fresh Ubuntu box (tested on 12.04)

# Pull this file down, make it executable and run it with sudo
# wget
# chmod u+x
# sudo ./

if [ $(id -u) != "0" ]; then
echo "You must be the superuser to run this script" >&2
exit 1
apt-get update

# Install the build tools (dpkg-dev g++ gcc libc6-dev make)
apt-get -y install build-essential

# automatic configure script builder (debianutils m4 perl)
apt-get -y install autoconf

# Needed for HiPE (native code) support, but already installed by autoconf
# apt-get -y install m4

# Needed for terminal handling (libc-dev libncurses5 libtinfo-dev libtinfo5 ncurses-bin)
apt-get -y install libncurses5-dev

# For building with wxWidgets
apt-get -y install libwxgtk2.8-dev libgl1-mesa-dev libglu1-mesa-dev libpng3

# For building ssl (libssh-4 libssl-dev zlib1g-dev)
apt-get -y install libssh-dev

# ODBC support (libltdl3-dev odbcinst1debian2 unixodbc)
apt-get -y install unixodbc-dev
mkdir -p ~/code/erlang
cd ~/code/erlang

if [ -e otp_src_17.0.tar.gz ]; then
echo "Good! 'otp_src_17.0.tar.gz' already exists. Skipping download."
tar -xvzf otp_src_17.0.tar.gz
chmod -R 777 otp_src_17.0
cd otp_src_17.0
make install
exit 0

Here’s an introduction to distribution in Erlang. This screencast demonstrates creating three Erlang nodes on a Windows box and one on a Linux box and then connecting them using the one-liner “net_adm:ping” to form a mighty compute cluster.

Topics covered:

  • Using erl to start an Erlang node (an instance of the Erlang runtime system).
  • How to use net_adm:ping to connect four Erlang nodes (three on Windows, one on Linux).
  • Using rpc:call to RickRoll a Linux box from an Erlang node running on a Windows box.
  • Using nl to load (deploy) a module from one node to all connected nodes.

For a deeper dive into distributed Erlang here’s the official reference.

Introduction to Distributed Erlang from Bryan Hunter on Vimeo.