Since Basho Technologies was founded back in mid-2007, we have been the recipients of a fair amount of (often unsolicited) advice regarding our business. No single facet of our business has prompted more commentary than the early decision to build our products using predominantly Erlang. From hiring to funding to adoption, otherwise smart people have predicted that Erlang would prove to be an Achilles heel for Basho. Not a single person outside the Erlang community -- with one notable exception -- saw Erlang as a strategic advantage.

In this talk, I will objectively consider the challenges and advantages we have faced over the past four years. I will share lessons learned seeking funding, recruiting, bui lding a Riak-oriented community, and driving adoption inside some of the world's largest enterprises. I will also talk about overcoming challenges our advocates have faced getting Erlang-based initiatives adopted in the enterprise.

Finally, I will discuss the role the Erlang community has played in our success and what I think the future can be for commercial and open-source projects that happen to be built on "that Swedish boutique language."

Given how popular writing your own Erlang web server seems to be these days, perhaps legendary Erlang programmer Claes "Klacke" Wikström was ahead of his time when nearly a decade ago he chose to call his then-new project "Yet Another Web Server." Famous for the "Apache vs. Yaws" graphs that boasted its scalability, Yaws has managed to maintain a relatively simple core while acquiring a rich set of features over the years. These features include the support of Erlang code embedded within HTML pages, mapping URI paths to specific application modules for request processing, streamed responses, web sockets, virtual servers, URL rewriting, integration with existing Erlang applications, sendfile support, and embedding within larger Erlang applications. When combined with the advanced concurrency, distribution, and reliability features of its underlying Erlang/OTP platform, Yaws provides a rich environment for production-quality web applications.

In this talk, Steve, a committer on the Yaws project, will provide an overview of a number of Yaws features and how applications use them, and will also explain some of its internal architecture.

Target audience: web developers

Talk objectives: Provide developers interested in Yaws with a tour of its features and design so they have a better understanding of how to use it.

PropEr is an open-source, Quickcheck-inspired tool for property-based testing in Erlang. Its salient feature, which is also the primary reason for PropEr's existence, is that it offers a proper integration of the language of types and specs of Erlang with properties. Any type can be used as a generator (PropEr knows how to create a shrinker for it) and any function spec can be directly used as simple property of a function.

In addition, PropEr offers support that significantly simplifies the task of writing generators for recursive and opaque data types. Last but not least, PropEr includes efficient support for testing stateful applications.

The talk will overview the features of PropEr and will include a PropEr demo.

Everyone wants to talk about "conversational web services" nowadays, but the mental model of a conversation tends to be constrained by what our current web services frameworks are capable of delivering.

Erlang was designed for controlling real-time services of "conversational quality", meaning that the service should allow people to meet and converse with a "real-life" feeling, without disruptive delays and with a life-like presentation of information. Web frameworks in Erlang have largely copied the traditional MVC frameworks, but for the back-end logic, they have drawn on the full power of Erlang's distributed, real- time processing environment. In effect, Erlang frameworks have been constrained by the long-polling RESTful nature of today's web services, but can now start breaking out of that mold, with the advent of web sockets and other real-time delivery technologies for the web. This talk will illustrate how Erlang provides all the tools necessary for building the next generation of truly conversational web services.

Let's take the following for-granted: Doing security, Privacy and Scalability last is a bad idea.

But you do not engineer a system that is supposed to have at the most a thousand users the same way you engineer a system that might have millions of them. That said, when you are constructing a Framework the assumptions you make on the use cases and number of users are at best a wild guess. Developers are like that, crazy. Even if you get a lot of really smart people in a room there is a very good chance you'll get it wrong. Enough to look at the IPV4 address space... but if IPV6 addresses were implemented at the beginning of the Internet the network overhead might have been unacceptable. Maybe the whole thing would not have worked. So one of the major issues when designing a new system that does not have a very strict, limited and stable use case, is writing only the code of the scalability you need while deferring that of future needs while having a very strong notion of why there are no strict impediments for it to scale later.

We will look at some of the design decisions at the heart of U.C. Engine our Realtime Collaboration Framework, and see why choosing a documented oriented store as a persistence layer is a good idea when there are some assumptions that are too early to be made. Why and how it allows us to defer some of the scalability issues. We'll look specifically at MongoDB that we chose it side by side with Mnesia. We shall examine the issue of impedance mismatch between records and documents. And to get really down to the nitty gritty stuff we will also take a hard look at the current state of MongoDB libraries in Erlang. Why we chose emongo, what we learnt from this about the state of libraries in Erlang and how this effects doing a larger web oriented open source project.

At Extreme Forge, we believe that the most efficient and enjoyable way to successful projects is to focus on having clean code that works. In the wake of test-driven development, software craftsmanship and coding dojos, we are working on an contest engine that allows people from around the world to gather online and compete for fun and learning on an interesting coding problem, in real-time.

A beta session of what we called the Agile Cup was held in April, where the problem was to find the way out of a maze of increasing complexity. In addition to solving mazes, the competitor's program must communicate with the engine through an HTTP/JSON interface.

I will code, live, an Erlang solution to this problem, in the hope of showing some clean Erlang code that works to the audience, and in order to provide a live, commented demonstration of the test-driven development approach to programming.

We present a framework in Erlang for distributed event processing and
data analytics in the domain of computational advertising and share
practical use cases and performance test results on ad serving events on
one of the largest online advertising networks. We also discuss related
technologies such as Hadoop, NoSQL, MPI/CUDA and Erlang's place in such
large-scale data analysis ecosystem.

We believe that one should never have to choose between productivity and scalability, which has been the case with traditional approaches to concurrency and distribution. The cause of that has been the wrong tools and the wrong layer of abstraction and Akka is here to change that. Akka is using the Actors together with Software Transactional Memory (STM) to create a unified runtime and programming model for scaling both UP (utilizing multi-core processors) and OUT (utilizing the grid/cloud). Akka provides location and network transparency by abstracting away both these tangents of scalability by turning them into an operations and configuration task. This gives the Akka runtime freedom to do adaptive automatic load-balancing, cluster rebalancing, replication and partitioning. In this talk you will learn what Akka is and how it can be used to solve hard scalability problems.

The consistency model used by Riak is designed to continue operating well even when nodes in your Riak cluster are down or unreachable, a property which also makes it a good model for mobile data. To me, "down or unreachable" sounds a lot like "off or without-cell-phone-connectivity" - common states for a mobile device.

In this talk, I'll present Riak Mobile, a component that can be embedded into your iOS or Android application to make it a full Riak replication-aware peer. Typical usages for Riak Mobile is as a mobile content distribution platform using one-way sync; or with two-way sync to also push updated data back to your Riak cluster when the network is "eventually" available.

In the talk, I'll walk through how Riak Mobile works. The client-part of Riak Mobile does not require an Erlang VM. Rather, it comes as either a Java or an Objective-C component using SQLite for on-device storage, and thus integrates nicely into the native development environments. The server-part is an OTP application running with Riak. Riak Mobile uses a flow-based algorithm using Merkle trees and vector clocks optimized specifically for providing efficient incremental synchronization for slow, high-latency network conditions.

Whistle is a powerful, open-source platform designed to give developers the most flexibility in creating VoIP-enabled applications and services.

While APIs exist for interacting with Whistle via REST and AMQP in your language of choice, we will show you how to create your own Erlang-based whApps inside the Whistle application container. The container provides functionality for easily interacting with CouchDB, RabbitMQ, mochijson2-decoded JSON strings and more, all designed to be easy to use without you having to delve into the details.

We will show how, once you have the idea for your whApp in mind, bringing it to life as a prototype is straightforward and fast. In this session we will show the steps for building a simple auto-attendant module to answer a call, play a menu, record digits pressed and transfer the call..

Target audience: Erlang developers wanting to build new or extend existing applications with VoIP-enabled components. Benefit from the high-level interactions with the various parts of the infrastructure, helping to stay focused on the business portions of the code.

Talk Objectives: Introduce the audience to the Whistle platform, the infrastructure available to be taken advantage of, and build a simple VoIP whApp.

It comes without saying that web is not static, in many ways. It evolves at a rapid pace and poses new challenges to the web developers community regularly. So how do we deal with this? By relentless experimenting and constantly being at the bleeding edge.

This talk will cover bleeding edge techniques for building web apps in Erlang. "Thick" clients, Socket.IO magic, session-oriented development, redundant/fault-tolerant session management & other new developments in the Erlang ecosphere.

Couchbeam is an OpenSource project that provide a simple CouchDB framework in Erlang.

This talk will explore how to use couchbeam in your application from building a web application to use it to rewrite Couchapp a command line tool to manage couchapps (embedded CouchDB applications) from Python to Erlang. Everything you should know about Couchbeam and more generally how to use the possibilities provided by Erlang to provide generic ways to use CouchDB features in your application.

Complex Event Processing is a technology that enables the observation, orientation of, decision against and issuance of actions in low latency near real time. In a nutshell CEP (or Event Stream Processing, ESP) engines invert the traditional relationship between processing engines and data stores. Rather than persisting data on disk and querying in an ad hoc fashion. We take the query, optimize the hell out of it, compile it ultimately to native code and flood it with a high frequency of real time events. StreamBase is a commercial compiler oriented flow oriented (neither functional nor object oriented) CEP engine with a graphical development experience. Like Erjang & Erlang, it's event driven, tuple oriented, supports behaviour driven development.

This talk will introduce CEP, demonstrate integrations with Erjang and Erlang and look at how two tuple oriented technologies and their ecosystems can mutually benefit for the greater good of the developers and organizations that leverage them in mission critical environments.

Wrangler is an Erlang refactoring tool which provides a range of refactorings - including renaming, function extraction and generalisation - as well as facilities for clone detection and removal as well as improvement of the module structure of projects. Wrangler is integrated into emacs and Eclipse (via ErlIDE).

Up to now, you could only use the refactorings built into Wrangler, or dive deep into the internals to extend it. The latest version of Wrangler now provides a much easier way of defining and applying refactorings for yourself. All you need to do is implement them as a refactoring behaviour and they are accessible in emacs, and you can write descriptions of what the refactorings do using a combination of Erlang macros and templates that describe the particular changes to be made. You can also use the same facilities write new forms of code inspection equally easily.

After describing the DIY facilities and giving an overview demo of Wrangler we'll show how to use this DIY refactoring API in practice.

At wooga we build backends for games that have millions of daily users.

In the gaming business we have a write heavy environment, with a high frequency of requests, traffic bursts and distribution across many nodes. These are all problems we need to solve and keep in mind in order to write a system that stands the chance of supporting the required load.

How do you meet the challenge of writing a brand new system with performance in mind? Where should the line between necessary efficiency and premature optimization be drawn? How do you measure performances? How do we generate synthetic load that reflects real usage patterns? How do you know you have enough capacity? How do you combine all the above with safely introducing changes and new features working in a two people team?

We had to answer to all the above questions and we want to share the solutions we found and the problems that we consider still open.

Having spent time working in a number of functional languages in addition to Erlang such as Haskell, Scheme, Lisp, OCaml and others, there are many nice features of those languages that would increase expressivity of Erlang. In my case, having spent a couple of years working in Haskell before returning to the RabbitMQ fold, all sorts of features are “missing”, such as laziness, type classes, additional infix operators, the ability to specify precedence of functions, fewer parenthesis, partial application, more consistent standard libraries and do-notation. That’s a fair list, and it’ll take me a while to get around to implementing them all in Erlang, but here are two for starters.

'Cut' is a lightweight syntax for abstracting over expressions with holes in them. Similar to partial application, it permits implicit lambda abstraction without the line-noise of `funs'.

'Do' introduces Haskell's do-notation to Erlang together with an extensible implementation of monads.

Together, these extensions can be used to write code that is clearer of intent, more legible and maintainable than would otherwise be the case.

Ascertaining program correctness through testing is limited because it is inherently hard to cover all possible execution scenarios through finite test runs. An alternative, albeit complementing technique to testing is that of Runtime Verification, whereby a monitor program runs concurrently with the main program and performs runtime checks with respect to the main program's current execution.

Erlang is particularly suited to such a technique. Due, in part, to its lack of static checks, the language has traditionally advocated for programs that incorporate precautionary runtime checks; these defensive checks make programs resilient to unforseen circumstances not covered by the normal program logic. Moreover, Erlang's native support for concurrent processes, together with the recent advent of multicore architectures, should in theory enable the deployment of monitor programs running concurrently with the main program at a negligible runtime cost.

In this talk we advocate for a Runtime Verification approach to Erlang program development where runtime checks are teased apart from the actualy program logic, and delegated to a separate monitor program. In some sense, this is an extension of the existing link/monitor mechanism in Erlang; at present this only comes into force once a monitored process dies; through native mechanisms such as tracing and messaging, this can however be made aware of the intermediate execution of programs so as to be able to check whether this execution adheres to some specified property. This approach carries with it a number of advantages: i) it yeilds better separation of concerns, where the main code is not cluttered with runtime checks obscuring the main program logic;ii) it allows for the monitored properties to be specified using independent property-based logic tools. Properties written in this logic can then be synthesised automatically into an Erlang monitor process and deployed.iii) it allows for a more modular approach to property monitoring, whereby properties monitored can be changed without affecting the main code of the program.

We evince this approach by adapting Larva, an existing tool for monitoring Java programs, to monitor Erlang program executions with respect to automata-based properties. We discuss our achievements so far and outline exciting directions for future work.

Since the release of Erlang/OTP on GitHub the possibilities for the
Erlang community to contribute to the development of Erlang has
increased tremendously. We should leverage this possibility and the
increased interest in Erlang to keep Erlang as a living and growing
language by letting the community help the language evolve. In this
slot, Erik will present the EPP process and committee.

The
committee members present at the Erlang Factory will participate in a
panel discussion together with the audience discussing the most
important EEP proposals.

Demonware is one of the world's largest online game service providers. We handle over 2.5 million concurrent online users, and host the online component for over 40 titles including Call of Duty Black Ops, the world's best selling game. Games studios come up with feature requests, and we develop the server code, figure our how to scale it and then keep it running for years.

We use Erlang mostly for what it was designed - highly concurrent loads. In our case we need to manage 100,000s of concurrent TCP connections across many physical machines each with many cores, sending messages between those users. We need a presence system to prevent duplicate logins and re-use of licenses, and a queuing system to schedule requests onwards to components built in a more sequential style. And we want this to have a webservice and SNMP interface, so we can control and monitor everything.

It's rare that our business logic itself is written in Erlang, but we do sometimes use it for game-related tasks. We use it as a server for caching in-game leaderboards, for allowing a user to test their bandwidth, and for holding some transient in-game user data.

This talk will be a brief history of the company, from scrappy startup, and why we made the switch to Erlang over four years ago. We will talk about how we use Erlang, and the various mistakes we have made and lessons we have learned over that time.

ejabberd is the most popular XMPP server. It will turn 9 years old this year and connects millions of users everyday. One of the main reasons? It's written in erlang!

This presentation will focus on what edge erlang gives to ejabberd. We will talk about mnesia, pattern matching, clustering and all the other nice features we get for free with erlang, and how we use them in ejabberd.

While this is not a technical talk, the attendance may be exposed to some short erlang snippets.

MIG’s new Erlang based product, the Interactive Broadcast Platform (IBP) has been designed to act as a supplementary channel for viewers to interact with, consumer content and vote on live television shows. IBP now provides viewers with a rich and engaging live show experience – a global first for this type of viewer participation.

Talk Objectives: The invention and concept of MIG's paid-for social-media interaction engine. The rational and choice of cloud based hosting. The challenge of scaling an Erlang/RIAK based application in the cloud

Having well defined reusable types for Erlang applications is a problem that many have talked about but no one has acted upon. In the course of creating Erlware Commons a need was discovered for these types so it was undertaken to provide a straight forward, easily understandable implementation along with reusable property based testing. This talk follows the process from inception, to implementation, providing very good examples of behaviour use, property based testing and iterative approach to development with tightly integrated automated testing.

Modern applications (web or otherwise) use Erlang because of its asynchronous nature. It seems a shame we can't easily extend this asynchronous paradigm into our data access layer. Heretofore we have been constrained by the support (or lack thereof) of asynchronous access to our data in the client. A pair of new utilities aim to work toward changing that (for the better, of course). By leveraging a custom RabbitMQ exchange type that stores every message it gets in Riak and a postcommit hook for Riak that fires every entry it sees an update on to a RabbitMQ broker, you can get fully asynchronous access to your data that isn't limited to a client--or even client platform.

In this talk I will give a little background of the development of these utilities and why I've been carrying a torch for asynchronous data access. I'll show examples of the uses of these utilities together, as well as using only the custom RabbitMQ exchange type for auditing messages, or using only the Riak postcommit hook for freshening caches.

Race conditions are among the worst kind of problem to debug: they tend to appear only rarely (and unrepeatably), often arise only in long running cases in production, and leave little evidence of what went wrong. Erlang is not immune to race conditions, despite its excellent support for concurrency, and they can give rise to rare intermittent failures in OTP libraries such as mnesia, the OTP database. Mnesia is known to fail "once every month or two" in production, and race conditions are one likely cause.

One reason race conditions tend not to be found earlier is that it is hard to write unit tests that might reveal them; thus they are not usually found until integration testing at the earliest. Moreover, the unit tests needed are always concurrent, and can be rather intricate and unobvious. Recently we extended QuickCheck with features to generate concurrent unit tests to provoke race conditions, and shrink them to minimal examples. With less than 200 lines of QuickCheck code, I was able to generate concurrent tests of dets (the disk storage layer of mnesia), and provoke five separate race conditions in short order. I'll explain the technique, which is easy to apply to any software specified by a QuickCheck state-machine.

The social entertainment platform of IMVU has grown to tens of millions of customers. We recently replaced an aging messaging architecture with a re-engineered message queue, reducing hardware requirements and latencies by a factor of 10 or better. We will cover the problems we set out to solve, which off-the- shelf solutions we considered and why they came up lacking, and the system design we ended up with. We will also talk about why we chose to implement the system in Erlang rather than more traditional languages like C++, Java or Python. Finally, we will show how this system scales well beyond millions of connected clients. Special attention will be given to how Erlang can be integrated into an existing web-based systems architecture, and some challenges that had to be overcome to use Erlang in the context of a continuous deployment environment.

RabbitMQ is emerging as good solution for open source messaging in modern architectures. This opens new challenges on how to implement integration patterns in order to go beyond simple produce/consume applications. In this presentation we will show how to implement several messaging patterns using RabbitMQ as backend technology such as:

Meck is a fairly new mocking library for Erlang that enables you to easily mock Erlang modules during testing. You can create modules, add functions, specify return values and throw exceptions. You can also look at a history of the calls made to the module, and make assertions based on that history. Meck can be used for any kind of testing, but is particularly useful in unit or component testing where it is often difficult to handle dependencies on external components or libraries.

Meck has been used in production in many different projects for about a year.

At Mochi we've spent a lot of time learning about how stressful and time consuming it is to let bad code slip into production. We've also learned a lot about how to avoid these mistakes by using tools to help us improve code quality and prevent regressions. My goal with this talk is to document and demonstrate the techniques we've developed to make our Erlang code better, hopefully saving you from making some of the mistakes we've made in the past.

Target Audience: Erlang developers who should be writing more and better tests

Talk objectives: Tips and tricks for how to infect your codebase with tests

The consumer 3D Printing market is exploding, democratising manufacturing and making it easy for anyone to produce what they can imagine. But design tools are either very expensive, difficult to use or not optimised for 3D printing.

I am creating Shapesmith to be an open-source, accessible and powerful 3D modeller for users who want to design high-fidelity 3D models cheaply. It runs in the browser using WebGL and an open source C++ solid modelling library. More importantly, Erlang is used on the server to provide a distributed, elastic solid geometry computation engine with a ReSTful interface.

Target audience: Technology enthusiasts who are interested in seeing a novel use of Erlang, and how it can be leveraged within a heterogeneous technology architecture.

The amount of software in a car is growing exponentially. This software has to be produced quickly, differentiate from the competition in functionality, multiplicity of features, and quality. There are several ingredients for enabling this, among them choosing the right technologies, improving the software process, and also being extremely thorough and efficient in testing.

The automotive industry have standardized their components in the AUTOSAR standard. Each component has about 500 pages thorough specification behind it, but many corners can be cut if the car need only part of the features; making the software faster and run on cheaper hardware.

Integration of components from different vendors is a nightmare for car companies. The vast amount of different configurations and scenarios in which the software should operate require an enormous and practically impossible amount of test cases to be written. Smart design of tests is tempting, but it is easy to overlook a corner case or combination one cannot foresee.

We created QuickCheck models for 3 major AUTOSAR components. The models are about 10% of the size of the implementation and condense 500 pages of specification in 1500 lines of Erlang code. The models take a configuration and software component as input and automatically generate and run thousands of tests against that component. We have been able to find anomalies in all provided, well tested, software components. We cover many more scenarios and tricky combinations than manual test cases are able to cover. Moreover, we can re-use the model for any given implementation and configuration.

With this technology we can increase test efficiency dramatically, find more errors and only invest a fraction of what it takes to write manual test cases.

It should not surprise anyone that Ericsson has great in-house components written in Erlang for modern multimedia networks. Their battle-proven DIAMETER stack, used in a number of Ericsson products, was included in the latest release of Erlang/OTP. In this talk, we will describe why this is exciting, what DIAMETER is, and where and how it is used in modern multimedia networks to enable subscriber and resource management, presence and billing. We will show how the Erlang/OTP DIAMETER stack leverages the unique features of Erlang, and contributes to making Erlang/OTP an ideal platform for building innovative - and profitable - applications on top of the emerging global service delivery infrastructure.

The roots of Erlang come from the work we did in the early 1990's. The requirements on software for telecommunication systems are very similar to the requirement we have today on software for highly concurrent, distributed, many core system often which must not stop and cannot be taken down for maintenance. This talk will examine the roots of Erlang and why requirements from the 1990's fit so well with today's needs.

After working as a manager (without pointy hair) for more than 20... years, Mike will also offer some advice about what not to tell your managers.

Systems in perfect, failure-free environments are boring. What happens to message passing protocols when CPUs are slow/overloaded, networks fail for 10 seconds (or 10 days), and processes crash? Systems reacting to failure are *much* more interesting to study and much more difficult to debug in the real world.

Scott will discuss a tool built with PropEr and QuickCheck (and perhaps McErlang) to find interesting protocol bugs where it's easy (i.e., on your desktop) instead of where it is hard/impossible (i.e., in your customer's production network). See https://github.com/slfritchie/msgdropsim for the source code, documentation, and sample protocol simulation.

Heroku runs a cloud platform composed of heterogeneous components (written in Ruby, Erlang and Go to name a few). Facilitating communication and syncing state between these components is a challenging task. Redis provides a simple, common interface as well as characteristics such as speed, scalability and redundancy. The list of uses we've found for Redis includes a redundant cache of shared state data, a means of tracking dynamic clusters of running instances, a container for realtime statistics data and a transient data store for high volumes of log messages. In this talk we will be discussing the details of how Redis fits into the architecture of multiple Erlang components in the Heroku platform. We will also review a handful of open source Erlang Redis utilities that we have found to be useful.

When battling technical debt, a fast growing biz and a rapidly changing market, Erlang is a major asset in your toolbox.

Talk Objectives: Highlight the strengths of Erlang (concurrency, horizontal scalability etc) from a biz perspective and describe the process of getting a "buy in" from CEOs and other suits for home grown solutions and niche techs such as Erlang.

Target Audience: Engineers who wants to listen to the biz version of Erlang, project managers, C crowd (CIO/CTO/CEO) etc etc

Even if Erlang technical relevance has been proven on large scale applications, the choice is still being questioned when you want to kickoff an open source project. Indeed, while Erlang community is still expanding, as of now it remains small compared to mainstream languages.

Even though, we were crazy enough to decide to use Erlang as the core technology of U.C.Engine, our young open source project. This presentation will share our thinking, debates and doubts that led to that decision, we will also discuss the specific actions that we implemented to help U.C.Engine grow.

This presentation should be more of a conversation and contributors to other open source projects are welcome to join and share with the audience.

Target audience: Anyone interested in using Erlang for an open source project.

Talk objectives: share with the audience how we can create a gradual contribution curve for an open-source Erlang project.

ZeroMQ is a message queuing socket library that allows us to build fast,
scalable messaging systems across many languages, and over TCP,
multicast, IPC, or between threads, or any mix thereof. ØMQ has bindings
for a huge variety of languages, including Erlang. In this talk we will
look at ZeroMQ, the basic messaging patterns it supports with some
example cases, and how it can be used to bridge between an Erlang system
and components in other languages.

Note: this is a "give me a break
from Erlang" talk primarily, but will have examples of the Erlang
bindings so developers can get a feel for how they might integrate
ZeroMQ messaging into their existing applications.

Erlang is perfectly suited for a modern distributed world. Part of this world is also a relatively new kind of client/server paradigm, namely Peer-to-Peer communication. We believe that this kind of communication is important to the modern internet and hence, the eTorrent project was born to gauge the usefulness of Erlang in a heavily distributed Peer-to-peer setting.

This talk is about using Erlang for implementing Peer-to-Peer clients. I claim Erlang made us write an efficient BitTorrent client in a fraction of the effort compared to other clients. I claim our client is more robust than the competition for normal operation. And I claim the Erlang mentality fits the Peer-to-Peer model well. I also explain how we utilize the Erlang platform to implement the client in an OTP-idiomatic way, and how we differ from the mainstream implementations.