Thomas - Programming Elixir: functional - concurrent - pragmatic - fun

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC.

Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein.

Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://pragprog.com.

We strongly recommend that you read this book with the publisher defaults setting enabled for your reading device or application. Certain formats and characters may not display correctly without this setting. Please refer to the instructions for your reader on how to enable the publisher defaults setting.

I have always been fascinated with how changes in hardware affect howwe write software.

A couple of decades ago, memory was a very limited resource. It madesense back then for our software to take hold of some piece ofmemory and mutate it as necessary. However, allocating this memory andcleaning up after we no longer needed it was a very error-pronetask. Some memory was never freed; sometimes memory was allocated overanother structure, leading to faults. At the time, garbage collectionwas a known technique, but we needed faster CPUs in order to use it inour daily software and free ourselves from manual memorymanagement. That has happenedmost of our languages are nowgarbage-collected.

Today, a similar phenomenon is happening. Our CPUs are not getting anyfaster. Instead, our computers get more and more cores. This means new software needs to use as many cores as it can if it is to maximizeits use of the machine. This conflicts directly with how we currently writesoftware.

In fact, mutating our memory state actually slows down our softwarewhen many cores are involved. If you have four cores trying to accessand manipulate the same piece of memory, they can trip over eachother. This potentially corrupts memory unless some kind ofsynchronization is applied.

I quickly learned that applying this synchronization is manual, errorprone, and tiresome, and it hurts performance. I suddenly realized thats nothow I wanted to spend time writing software in the next years of mycareer, and I set out to study new languages and technologies.

It was on this quest that I fell in love with the Erlang virtualmachine and ecosystem.

In the Erlang VM, all code runs in tiny concurrent processes, each with its own state. Processes talk to each othervia messages. And since all communication happens by message-passing,exchanging messages between different machines on the same network ishandled transparently by the VM, making it a perfect environment forbuilding distributed software!