Bag End by Jesse Leite

Clause and Effect

2026-03-09T00:00:00+00:00

At the end of the last post, I used a multi-clause function to demonstrate the power of pattern matching in Elixir. What are multi-clause functions though, and how is this even possible?

In many languages, a function is defined by name only, and you can only have one function with a given name per class or namespace.

For example, if you redeclare the same greet() function twice in PHP, it will blow up with a FATAL ERROR:

class Message
{
    public function greet(User $user): string
    {
        return "Welcome, {$user->name}!";
    }

    public function greet(Contact $contact): string
    {
        return "Welcome, {$contact->displayName}!";
    }
}

# FATAL ERROR - Cannot redeclare Message::greet()

As we've learned though, Elixir allows for pattern matching across multiple function clauses with the same name, where you can define the various shapes of data that a function can accept:

defmodule Message do
  def greet(%User{} = user) do
    "Welcome, #{user.name}!"
  end

  def greet(%Contact{} = contact) do
    "Welcome, #{contact.display_name}!"
  end
end

This is totally valid Elixir. When calling Message.greet(contact) with a %Contact{} struct as an argument, Elixir will use pattern matching to pass over the first %User{} clause, running the second clause instead.

As long as the shape of the arguments is distinct enough to pattern match without ambiguity, Elixir will treat both of these as valid compilable function clauses.

More than just the shape of the arguments, Elixir also considers the number of arguments in any given function definition. This is called arity, and you'll often see this referenced as function_name/arity:

# This is `greet/1` (because it has one argument)
def greet(%User{} = user) do
  "Welcome, #{user.name}!"
end

# This is `greet/2` (because it has two arguments)
def greet(%User{} = user, %Time{} = time) do
  cond do
    time.hour in 0..11  -> "Good morning, #{user.name}!"
    time.hour in 12..17 -> "Good afternoon, #{user.name}!"
    time.hour in 18..23 -> "Good evening, #{user.name}!"
  end
end

Now if we call greet(user, time) with two arguments, Elixir will know to run the second greet/2 clause because of function arity.

The important thing to note here is that a function's identity is both its name and its arity — so greet/1 and greet/2 are totally separate functions, not overloads of the same function. This mainly matters for control flow, but there are more uses for arity which we'll cover in a future post.

You can see how pattern matching and arity can really clean things up, but what about that nested cond expression inside my greet/2 clause? If we want to remove a layer of nesting here, we can extract to the top level using when guard expressions:

def greet(%User{} = user, %Time{hour: h}) when h in 0..11 do
  "Good morning, #{user.name}!"
end

def greet(%User{} = user, %Time{hour: h}) when h in 12..17 do
  "Good afternoon, #{user.name}!"
end

def greet(%User{} = user, %Time{hour: h}) when h in 18..23 do
  "Good evening, #{user.name}!"
end

Finally, maybe we also want to have a simple fallback greet/0 clause for when we don't have person or time arguments to pass:

def greet do
  "Greetings!"
end

Now why does all of this really matter? 👀

In PHP, if you wanted a greet() function to handle all of the edge cases we've touched on, you would have to get clever with nested conditions and guards inside your function, maybe something like this:

public function greet(User|Contact|null $person = null, ?DateTime $time = null): string
{
    if (! $person) {
        return "Greetings!";
    }

    $hour = $time?->format('G');

    if ($time && $hour >= 0 && $hour <= 11) {
        $greeting = "Good morning";
    } elseif ($time && $hour >= 12 && $hour <= 17) {
        $greeting = "Good afternoon";
    } elseif ($time && $hour >= 18 && $hour <= 23) {
        $greeting = "Good evening";
    } else {
        $greeting = "Welcome";
    }

    if ($person instanceof User) {
        $name = $person->name;
    } elseif ($person instanceof Contact) {
        $name = $person->displayName;
    }

    return "{$greeting}, {$name}!";
}

This honestly isn't so bad! You could even clean this up by extracting smaller getGreeting($time) and getName($person) helpers, but the complexity of logic required within a single greet() definition as an entry point remains.

Elixir, on the other hand, lets you flatten greet() into simpler, hyperfocused function clauses:

def greet(person, %Time{hour: h}) when h in 0..11 do
  "Good morning, #{name(person)}!"
end

def greet(person, %Time{hour: h}) when h in 12..17 do
  "Good afternoon, #{name(person)}!"
end

def greet(person, %Time{hour: h}) when h in 18..23 do
  "Good evening, #{name(person)}!"
end

def greet(person) do
  "Welcome, #{name(person)}!"
end

def greet do
  "Greetings!"
end

defp name(%User{} = user) do
  user.name
end

defp name(%Contact{} = contact) do
  contact.display_name
end

Using all of these multi-clause techniques together (pattern matching, arity, and guard expressions), our clauses are now:

Easier to read
Easier to extend
Easier to test
Easier for AI to reason about
More token-efficient for LLMs

Don't. Sleep. On. Elixir. 😎

Pattern Match Made in Heaven

2026-02-28T00:00:00+00:00

In most languages, = is merely an assignment operator. In Elixir, = is actually called the match operator, and it's one of the first things you'll learn in Elixir that might just completely rewire your brain!

Of course, we can still use = for basic assignment:

name = "Jesse"

But what's actually happening here is that Elixir is matching the left side against the right side, binding matched variables along the way.

This becomes powerful when you start matching against more complex data structures:

{:ok, value} = {:ok, 42}
# value is now 42

{:error, reason} = {:error, "not found"}
# reason is now "not found"

This is not unlike basic destructuring in PHP or JS:

const [status, value] = ["ok", 42];

Except in JS, a failed destructure silently gives you undefined, not to mention both PHP and JS are quite limiting when it comes to what you can do with destructuring.

Elixir's pattern matching is on a whole different level, because Elixir also asserts the shape.

For example, when using the = match operator, a failed match will blow up with a MatchError:

{:ok, value} = {:error, "not found"}
# ** (MatchError) no match of right hand side value: {:error, "not found"}

Or when pattern matching within case, cond, with, etc., you can branch on possible matches, which can make for some really elegant error handling:

case Http.get(url) do
  {:ok, %{status: 200, body: body}}
    -> Jason.decode!(body)

  {:error, %{status: 403}}
    -> View.render(:forbidden)

  {:error, %{status: 404}}
    -> View.render(:not_found)

  {:error, _}
    -> Logger.error("Response failure!")
end

This starts to get really crazy when you realize that you can pattern match nearly anywhere in Elixir!

For example, instead of handling branching logic via conditionals within a function's body, you can pattern match right in the definition itself:

defp response({:ok, %{status: 200, body: body}}) do
  Jason.decode!(body)
end

defp response({:error, %{status: 403}}) do
  View.render(:forbidden)
end

defp response({:error, %{status: 404}}) do
  View.render(:not_found)
end

defp response({:error, _}) do
  Logger.error("Response failure!")
end

Elixir will then check each function clause in order until it finds a pattern match, to determine which clause to run.

Say we pass the response() function an {:error, response} tuple with a response.status of 404, then our second 'not found' view render clause will run.

Once you start thinking in patterns, it will fundamentally change how you handle data, errors, and control flow. Instead of writing defensive checks and nesting conditionals, you can often just describe the shape of the data you expect, and Elixir will do the rest ...How neat is that!?

The Glorious Pipe Operator

2025-09-22T00:00:00+00:00

One of the first game-changing features people learn about in functional programming is the pipe operator, which allows us to pass and transform data fluently through a pipeline.

In Elixir, the |> operator simply takes the result of an expression on the left side, and passes it as the first argument to the next function on the right side:

names |> Enum.sort() |> Enum.uniq()

This is essentially equivalent to passing the output of sort() directly into uniq():

Enum.uniq(Enum.sort(names))

The most obvious benefit of the pipeline is that it restructures nested funtions from an inside-out to a much more readable left-to-right, or even top-to-bottom fashion:

title
|> String.trim()
|> String.downcase()
|> String.replace(" ", "-")

It also eliminates the need for creating temporary variables, and helps with debugging and refactoring, etc.

If you're coming from Laravel, you're probably familiar with Laravel's fluent collection and string helpers:

str($title)
    ->trim()
    ->lower()
    ->replace(" ", "-")
    ->toString();

On the surface, this looks nearly the same as my Elixir example above, but it's actually much more complex under the hood:

Firstly, str() creates an Illuminate\Support\Stringable instance, with the primitive stored on the object.
At this point, we're only allowed to call methods that exist within the Stringable class, like trim(), lower(), and replace().
To remain fluent, each of these methods must return $this under the hood.
At the end of the chain, we're still left with a Stringable instance, so we need to cast the output to string, or call ->toString() to get a primitive string as a result.

If you've ever tried to built your own fluent API in an object-oriented language like PHP, these concepts will be familiar to you:

You manage the state on the object yourself.
You return $this from every method.
You offer a getter method to grab and/or cast that final state at the end of a pipeline.

In Elixir, functional pipelines are much simpler, because the |> operator is implemented at the language level, and it works on any function.

There is no state to manage, the raw output is passed through each step of the pipeline, and no special getter is needed to cast the final result. In fact, you can even pipe functions across modules!

csv
|> String.split(",")
|> Enum.map(&String.trim/1)
|> Jason.encode()

This little functional |> operator is quite the paradigm shift coming from OOP, and I'm finding that it really helps to simplify and improve code readability and composability.

Interestingly, the pipe operator is coming to PHP 8.5! I have little doubt that the PHP and Laravel communities will be all over it!

Elixir for PHP Devs

2025-09-16T00:00:00+00:00

Diving into Elixir has been a blast so far! Its functional paradigms are challenging the way I think about programming, and are a big reason why I'm excited to start blogging again.

I may not have the expertise to teach Elixir, but I have a career of experience in object-oriented programming, and I think it would be fun to approach this series of posts from that vantage point!

For starts, I would like to cover Elixir's functional programming concepts. Let's talk about Elixir's language features, and how they contrast with PHP as an OOP language.

Next, I'd like to dive into how running on the Erlang VM platform makes Elixir extremely scalable and fault tolerant.

Finally, as a long-time Laravel dev, I'll no doubt want to chronicle my journey with Phoenix from a Laravel perspective. I'm sure many Rails devs have made this jump given Elixir's history with Ruby, but I haven't seen much crossover into Elixir from the PHP world, and think that angle could be interesting.

Wherever you come from though, my goal is to infect you with that sweet functional Elixir-pilled excitement. Let's do this!

A New Chapter

2025-09-14T00:00:00+00:00

Hello and welcome!

My name is Jesse Leite, and I am a software developer from Ontario, Canada. In a recent turn of events, I find myself at a bit of a crossroads with an exciting new job on the horizon...

Incredibly excited to share that today I officially accepted a new job offer and position at @savvycal! 🙏

Super rad product, and neat tech stack too! Elixir + Phoenix + Inertia + React, lessssgo! 💪 https://t.co/s0ows8CIPj
— Dr. Elvim Ransom 👽 (@jesseleite85) September 9, 2025

Of course, this is a very bittersweet move after being at Statamic for the last 7 years. I'm very grateful for all the kindness that team and community have shown me over the years. That said, I'm beyond excited to be joining the SavvyCal team!

After having spent the last ~10 years of my professional life in Laravel and Vue, I figure this new chapter will be a perfect opportunity to try blogging again as I hop ecosystems and dive into the new Elixir + React stack. For example, expect nuggets about my functional programming learnings as a long-time OOP dev!

Outside of all that, I'm also a husband, proud father, Christ follower, and all-around flawed human being. I enjoy music, reading, gaming, and sometimes even going outdoors! I may blog about some of these topics from time to time, but it'll mostly be focused around software and dev.

In order to make things easy on myself, I'm going to treat this as a microblog of sorts. Instead of long posts and in-depth tutorials, I hope to publish more bite-sized thoughts and musings to keep things regular. Short and sweet!