There’s a function called Enum.map in Elixir that works on multiple collection types, but it's not without its issues. In this post, I will introduce you to a concept from functional programming called a functor. We’ll make a Functor protocol with a function called fmap that will aspire to be a better version of Enum.map. Note: The article is inspired by the Witchcraft library, which we covered in one of our previous posts. But first: what's the problem with Enum.map exactly?

This is the first part of a two-part series about maintainable code in Elixir. In this part, we will show how code predictability plays a crucial role in a project's short and long-term health. We will use Elixir's built-in features for this, like the pipe operator, tuples, and with blocks. First, we'll explain what predictability is and why it is so important. Then we will go through some tools that Elixir already has and how you can use them to write better code.

Phoenix LiveView lets you develop full-stack apps with client-side interactions while mostly avoiding cross-stack hassle. Assigns, managed by the LiveView socket, are a core tool for making that happen — allowing you to store, present, and update data effortlessly and efficiently. But as they do so much, assigns come with their own complexities and may backfire if misused.

Elixir is a dynamically-typed language. Types in Elixir are checked when a program runs, not when it compiles. If they don’t match up, an exception is thrown. In statically-typed languages, types are checked during compile time. This can help us write code that is correct, understandable, and refactorable. But it also introduces a certain focus on types as the foundation for your application. One interesting concept is to use types to model your business domain.

While initially conceived as a tool for data exploration (much like Jupyter for Python), Livebook has deservedly become a sensation in the Elixir community. It has been fantastic to see all the wonderful ways teams are leveraging Livebook for a range of different use cases. We have seen Livebooks being used to: Livebooks have also been used as the default REPL interface for project development.

In this post, we will explore how event-driven architecture can make your app more responsive for users and decouple your modules for a better developer experience. We will also look at several methods of implementing event-driven architecture with Elixir. Elixir is particularly good for this because of the advanced and concise message-passing APIs that it offers and BEAM's outstanding support for concurrency. But first: what is event-driven architecture, exactly?

Elixir is all about performance. Say you have an app up and running with Elixir, but some parts aren't working as fast as you would like them to. That is where profiling comes in. Profiling tools usually walk you through the frequency and duration of function calls and where they spend their time. Erlang has impressive profile tooling available at its disposal. In this post, we will look into three profiling tools in Elixir: cprof, eprof, and fprof.

Thanks to HEEx and function components, LiveView provides developers with a sleek, ergonomic syntax for building and maintaining sophisticated interactive UIs. LiveView's form/1 function component is a great example of this, making it easier than ever before to render complex forms within LiveView. However, the form/1 function component can feel a little mysterious to anyone unfamiliar with LiveView's function components.

Keeping your dependencies up-to-date is essential to ensure that your applications stay healthy, secure, and performant. Thankfully, the BEAM ecosystem has its own package manager, Hex, which is fast, mature, and simple to use. This article explores the available tools and commands to manage Hex dependencies and some tips to make the process more enjoyable. Let's dive in!

While Elixir is a functional programming language, it is different from most of the other popular functional languages like Haskell, Scala, OCaml, and F#. Elixir pragmatically handles concurrent systems with high fault tolerance. In other words, Elixir is an FP language because this naturally fits it, and not for its own sake. So, porting idioms blindly from Haskell to Elixir can lead to undesired results.