Convert Elm to Elixir

Convert Elm code to idiomatic Elixir. This skill extends

meta-convert-dev

This Skill Extends

• meta-convert-dev

  - Foundational conversion patterns (APTV workflow, testing strategies)

For general concepts like the Analyze → Plan → Transform → Validate workflow, testing strategies, and common pitfalls, see the meta-skill first.

This Skill Adds

• Type mappings: Elm types → Elixir types and structs
• Idiom translations: The Elm Architecture (TEA) → Phoenix LiveView / GenServer
• Error handling: Elm Maybe/Result → Elixir tagged tuples and pattern matching
• Concurrency: Elm Cmd/Sub → Elixir processes, GenServer, and Supervisor
• Architecture: Frontend TEA → Full-stack Phoenix with LiveView

This Skill Does NOT Cover

• General conversion methodology - see

  meta-convert-dev

• Elm language fundamentals - see

  lang-elm-dev

• Elixir language fundamentals - see

  lang-elixir-dev

• Reverse conversion (Elixir → Elm) - see

  convert-elixir-elm

• Phoenix-specific patterns beyond basics - see

  lang-elixir-phoenix-dev

Quick Reference

String

String.t()

binary()

Int

integer()

Float

float()

Bool

boolean()

true

false

List a

list(a)

Maybe a

nil

{:ok, a}

{:error, reason}

Result err ok

{:ok, ok}

{:error, err}

( a, b )

{a, b}

type alias

defstruct

@type

type

@type

|

defmodule

Cmd msg

GenServer.cast/2

Sub msg

GenServer

Model

view

render/1

When Converting Code

1. Analyze source thoroughly - Understand TEA lifecycle and Cmd/Sub usage
2. Map types first - Create type equivalence table for domain models
3. Preserve semantics - TEA's guarantees (no runtime errors, managed effects) need OTP equivalents
4. Adopt Elixir idioms - Don't write "Elm code in Elixir syntax"
5. Consider architecture shift - Frontend-only TEA → Full-stack Phoenix LiveView or Backend API
6. Test equivalence - Same business logic outcomes

Type System Mapping

Primitive Types

String

String.t()

Int

integer()

Float

float()

Bool

boolean()

Char

String.t()

()

:ok

nil

:ok

Collection Types

List a

list(a)

Array a

list(a)

:array

( a, b )

{a, b}

( a, b, c )

{a, b, c}

Dict k v

Map.t(k, v)

Set a

MapSet.t(a)

Composite Types

type alias User = { name : String, ... }

defstruct [:name, ...]

@type

type Msg = Inc | Dec

@type msg :: :inc | :dec

type Msg = SetName String

{:set_name, String.t()}

Maybe a

nil | a

{:ok, a} | {:error, term()}

Result err ok

{:ok, ok} | {:error, err}

The Elm Architecture → Phoenix LiveView / GenServer

Model

socket.assigns

Msg

init : flags -> ( Model, Cmd Msg )

mount/3

update : Msg -> Model -> ( Model, Cmd Msg )

handle_event/3

view : Model -> Html Msg

render/1

Cmd Msg

send(self(), msg)

Sub Msg

PubSub.subscribe/2

Model

Msg

init

init/1

update

handle_call/3

handle_cast/2

Cmd

Sub

handle_info/2

Idiom Translation

Pattern 1: Maybe → Result Tuples

Elm:

type Maybe a
    = Just a
    | Nothing

findUser : Int -> Maybe User
findUser id =
    users
        |> List.filter (\u -> u.id == id)
        |> List.head

case findUser 1 of
    Just user ->
        user.name

    Nothing ->
        "Anonymous"

Elixir:

# Using nil
def find_user(id) do
  Enum.find(users(), fn u -> u.id == id end)
end

case find_user(1) do
  nil -> "Anonymous"
  user -> user.name
end

# Or using result tuples (more idiomatic for operations that can fail)
def find_user(id) do
  case Enum.find(users(), fn u -> u.id == id end) do
    nil -> {:error, :not_found}
    user -> {:ok, user}
  end
end

case find_user(1) do
  {:ok, user} -> user.name
  {:error, :not_found} -> "Anonymous"
end

Why this translation:

• Elm's

  Maybe

  is explicit about presence/absence
• Elixir uses

  nil

  for simple optionals or

  {:ok, value}

  /

  {:error, reason}

  for operations
• Pattern matching works similarly in both languages
• Elixir's tagged tuples provide more context (error reasons)

Pattern 2: Result → Tagged Tuples

Elm:

type Result error value
    = Ok value
    | Err error

parseAge : String -> Result String Int
parseAge str =
    case String.toInt str of
        Just age ->
            if age >= 0 then
                Ok age
            else
                Err "Age must be non-negative"

        Nothing ->
            Err "Not a valid number"

case parseAge "25" of
    Ok age ->
        "Age: " ++ String.fromInt age

    Err message ->
        "Error: " ++ message

Elixir:

@spec parse_age(String.t()) :: {:ok, integer()} | {:error, String.t()}
def parse_age(str) do
  case Integer.parse(str) do
    {age, ""} when age >= 0 ->
      {:ok, age}

    {_age, ""} ->
      {:error, "Age must be non-negative"}

    _ ->
      {:error, "Not a valid number"}
  end
end

case parse_age("25") do
  {:ok, age} ->
    "Age: #{age}"

  {:error, message} ->
    "Error: #{message}"
end

Why this translation:

• Direct mapping from Elm

  Result

  to Elixir tagged tuples
• Pattern matching syntax is very similar
• Elixir's

  with

  statement can chain multiple results (similar to Elm's

  Result.andThen

  )

Pattern 3: The Elm Architecture → Phoenix LiveView

Elm (Counter):

module Main exposing (main)

import Browser
import Html exposing (Html, button, div, text)
import Html.Events exposing (onClick)

-- MODEL

type alias Model =
    { count : Int }

init : () -> ( Model, Cmd Msg )
init _ =
    ( { count = 0 }, Cmd.none )

-- UPDATE

type Msg
    = Increment
    | Decrement

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        Increment ->
            ( { model | count = model.count + 1 }, Cmd.none )

        Decrement ->
            ( { model | count = model.count - 1 }, Cmd.none )

-- VIEW

view : Model -> Html Msg
view model =
    div []
        [ button [ onClick Decrement ] [ text "-" ]
        , div [] [ text (String.fromInt model.count) ]
        , button [ onClick Increment ] [ text "+" ]
        ]

main : Program () Model Msg
main =
    Browser.element
        { init = init
        , update = update
        , view = view
        , subscriptions = \_ -> Sub.none
        }

Elixir (Phoenix LiveView):

defmodule MyAppWeb.CounterLive do
  use MyAppWeb, :live_view

  # MOUNT (like init)
  @impl true
  def mount(_params, _session, socket) do
    {:ok, assign(socket, count: 0)}
  end

  # HANDLE_EVENT (like update)
  @impl true
  def handle_event("increment", _params, socket) do
    {:noreply, update(socket, :count, &(&1 + 1))}
  end

  def handle_event("decrement", _params, socket) do
    {:noreply, update(socket, :count, &(&1 - 1))}
  end

  # RENDER (like view)
  @impl true
  def render(assigns) do
    ~H"""
    <div>
      <button phx-click="decrement">-</button>
      <div><%= @count %></div>
      <button phx-click="increment">+</button>
    </div>
    """
  end
end

Why this translation:

• TEA's Model → LiveView's

  socket.assigns

• TEA's Msg → LiveView event names (strings/atoms)
• TEA's

  update

  → LiveView's

  handle_event/3

• TEA's

  view

  → LiveView's

  render/1

• TEA's

  Cmd

  → LiveView async operations (via

  send(self(), ...)

  or

  Task.async

  )
• LiveView handles the runtime (like Elm Runtime), managing concurrency and state

Pattern 4: List Processing

Elm:

processData : List Int -> Int
processData numbers =
    numbers
        |> List.filter (\x -> x > 0)
        |> List.map (\x -> x * 2)
        |> List.foldl (+) 0

Elixir:

def process_data(numbers) do
  numbers
  |> Enum.filter(&(&1 > 0))
  |> Enum.map(&(&1 * 2))
  |> Enum.sum()
end

# Or using reduce explicitly
def process_data(numbers) do
  numbers
  |> Enum.filter(&(&1 > 0))
  |> Enum.map(&(&1 * 2))
  |> Enum.reduce(0, &+/2)
end

Why this translation:

• Pipe operators work identically

• List

  module →

  Enum

  module
• Lambda syntax differs: Elm

  \x -> x * 2

  → Elixir

  &(&1 * 2)

  or

  fn x -> x * 2 end

• Both are lazy in comprehensions, eager in pipes

Pattern 5: Union Types → Pattern Matching

Elm:

type Status
    = Loading
    | Success String
    | Failure String

handleStatus : Status -> String
handleStatus status =
    case status of
        Loading ->
            "Loading..."

        Success data ->
            "Data: " ++ data

        Failure error ->
            "Error: " ++ error

Elixir:

# Using atoms and tagged tuples
@type status :: :loading | {:success, String.t()} | {:failure, String.t()}

def handle_status(status) do
  case status do
    :loading ->
      "Loading..."

    {:success, data} ->
      "Data: #{data}"

    {:failure, error} ->
      "Error: #{error}"
  end
end

Why this translation:

• Elm's union types → Elixir atoms (for zero-arg variants) and tagged tuples (for data-carrying variants)
• Pattern matching syntax is nearly identical
• Elixir's approach is more dynamic but equally powerful

Error Handling

Elm Error Model → Elixir Error Model

Maybe

Result

{:ok, val}

{:error, reason}

Result.andThen

with

Maybe

nil

{:error, reason}

Chaining Operations with Errors

Elm:

validateAndSave : String -> Result String User
validateAndSave input =
    input
        |> validateEmail
        |> Result.andThen createUser
        |> Result.andThen saveToDatabase

case validateAndSave "alice@example.com" of
    Ok user ->
        "Saved: " ++ user.name

    Err message ->
        "Failed: " ++ message

Elixir:

def validate_and_save(input) do
  with {:ok, email} <- validate_email(input),
       {:ok, user} <- create_user(email),
       {:ok, saved_user} <- save_to_database(user) do
    {:ok, saved_user}
  else
    {:error, reason} -> {:error, reason}
  end
end

case validate_and_save("alice@example.com") do
  {:ok, user} ->
    "Saved: #{user.name}"

  {:error, message} ->
    "Failed: #{message}"
end

Why this translation:

• Elm's

  Result.andThen

  for chaining → Elixir's

  with

  statement
• Both short-circuit on first error
• Elixir's

  with

  is more flexible (can handle multiple patterns)

Concurrency Patterns

Elm Cmd/Sub → Elixir Processes

Elm's concurrency is managed by the Elm Runtime - you describe side effects declaratively via

Cmd

Sub

Cmd (Commands) → Async Operations

Elm:

-- Cmd describes side effect; runtime executes it
type Msg
    = GotUsers (Result Http.Error (List User))

getUsers : Cmd Msg
getUsers =
    Http.get
        { url = "https://api.example.com/users"
        , expect = Http.expectJson GotUsers (Decode.list userDecoder)
        }

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        FetchUsers ->
            ( { model | loading = True }, getUsers )

        GotUsers result ->
            case result of
                Ok users ->
                    ( { model | users = users, loading = False }, Cmd.none )

                Err _ ->
                    ( { model | error = Just "Failed", loading = False }, Cmd.none )

Elixir (LiveView):

defmodule MyAppWeb.UsersLive do
  use MyAppWeb, :live_view

  def handle_event("fetch_users", _params, socket) do
    # Async task (like Cmd)
    send(self(), :perform_fetch)
    {:noreply, assign(socket, loading: true)}
  end

  def handle_info(:perform_fetch, socket) do
    case HTTPoison.get("https://api.example.com/users") do
      {:ok, %{body: body}} ->
        users = Jason.decode!(body)
        {:noreply, assign(socket, users: users, loading: false)}

      {:error, _reason} ->
        {:noreply, assign(socket, error: "Failed", loading: false)}
    end
  end
end

Elixir (GenServer):

defmodule UserFetcher do
  use GenServer

  def handle_cast(:fetch_users, state) do
    # Spawn async task
    Task.async(fn ->
      HTTPoison.get("https://api.example.com/users")
    end)

    {:noreply, %{state | loading: true}}
  end

  def handle_info({_ref, {:ok, %{body: body}}}, state) do
    users = Jason.decode!(body)
    {:noreply, %{state | users: users, loading: false}}
  end

  def handle_info({_ref, {:error, _reason}}, state) do
    {:noreply, %{state | error: "Failed", loading: false}}
  end
end

Why this translation:

• Elm

  Cmd

  → Elixir

  send(self(), msg)

  or

  Task.async

• Elm runtime guarantees serialized

  update

  calls → Elixir GenServer/LiveView handle one message at a time
• Both avoid race conditions in user code

Sub (Subscriptions) → PubSub / handle_info

Elm:

subscriptions : Model -> Sub Msg
subscriptions model =
    Time.every 1000 Tick  -- Every second

Elixir (LiveView):

def mount(_params, _session, socket) do
  if connected?(socket) do
    # Subscribe to Phoenix PubSub
    Phoenix.PubSub.subscribe(MyApp.PubSub, "events")

    # Or schedule periodic message
    :timer.send_interval(1000, self(), :tick)
  end

  {:ok, socket}
end

def handle_info(:tick, socket) do
  # Handle periodic event
  {:noreply, update(socket, :count, &(&1 + 1))}
end

def handle_info(%{event: "user_updated", payload: user}, socket) do
  # Handle PubSub message
  {:noreply, assign(socket, current_user: user)}
end

Why this translation:

• Elm

  Sub

  → Elixir

  Phoenix.PubSub

  or

  :timer

  or

  handle_info/2

• Both models ensure messages arrive one at a time in the update/handle loop

Common Pitfalls

1. Assuming Elm's "No Runtime Errors" in Elixir

   • Elm guarantees no runtime errors via its type system
   • Elixir has dynamic typing and exceptions
   • Fix: Use typespecs (

     @spec

     ), Dialyzer, and pattern match exhaustively

2. Forgetting Immutability Differences

   • Elm enforces immutability at language level
   • Elixir has immutable data but processes have mutable state
   • Fix: Never mutate GenServer state directly; always return new state

3. Misunderstanding Cmd/Sub → Process Translation

   • Elm's Cmd/Sub are declarative; runtime manages everything
   • Elixir requires explicit process spawning and message handling
   • Fix: Use GenServer/LiveView patterns, don't try to replicate Elm Runtime exactly

4. Over-using Exceptions

   • Elm has no exceptions
   • Elixir has exceptions but idiomatic code uses

     {:ok, val}

     /

     {:error, reason}

   • Fix: Use tagged tuples and pattern matching, reserve exceptions for truly exceptional cases

5. Ignoring OTP Supervision

   • Elm runtime handles all failures invisibly
   • Elixir requires explicit supervision trees
   • Fix: Use Supervisors to restart crashed processes ("let it crash" philosophy)

6. Not Leveraging Elixir's Strengths

   • Elm is frontend-only; Elixir is full-stack
   • Fix: Use Phoenix for backend + LiveView for reactive frontend; don't just replicate Elm's architecture

7. Type Alias vs Struct Confusion

   • Elm's

     type alias

     creates a record type
   • Elixir's

     defstruct

     creates a module-specific struct
   • Fix: Use

     defstruct

     for domain models,

     @type

     for type annotations

Tooling

Examples

Example 1: Simple - Type Alias to Struct

Elm:

type alias User =
    { name : String
    , email : String
    , age : Int
    }

createUser : String -> String -> Int -> User
createUser name email age =
    { name = name, email = email, age = age }

Elixir:

defmodule User do
  @type t :: %__MODULE__{
    name: String.t(),
    email: String.t(),
    age: integer()
  }

  defstruct [:name, :email, :age]

  @spec create(String.t(), String.t(), integer()) :: t()
  def create(name, email, age) do
    %User{name: name, email: email, age: age}
  end
end

Example 2: Medium - Result Chaining

Elm:

type alias ValidationError = String

validateUser : String -> String -> Int -> Result ValidationError User
validateUser name email age =
    validateName name
        |> Result.andThen (\_ -> validateEmail email)
        |> Result.andThen (\_ -> validateAge age)
        |> Result.map (\_ -> { name = name, email = email, age = age })

validateName : String -> Result ValidationError String
validateName name =
    if String.isEmpty name then
        Err "Name cannot be empty"
    else
        Ok name

validateEmail : String -> Result ValidationError String
validateEmail email =
    if String.contains email "@" then
        Ok email
    else
        Err "Invalid email"

validateAge : Int -> Result ValidationError Int
validateAge age =
    if age >= 18 then
        Ok age
    else
        Err "Must be at least 18"

Elixir:

defmodule UserValidator do
  @type validation_error :: String.t()

  @spec validate_user(String.t(), String.t(), integer()) ::
    {:ok, User.t()} | {:error, validation_error()}
  def validate_user(name, email, age) do
    with {:ok, _} <- validate_name(name),
         {:ok, _} <- validate_email(email),
         {:ok, _} <- validate_age(age) do
      {:ok, User.create(name, email, age)}
    end
  end

  defp validate_name(""), do: {:error, "Name cannot be empty"}
  defp validate_name(name), do: {:ok, name}

  defp validate_email(email) do
    if String.contains?(email, "@") do
      {:ok, email}
    else
      {:error, "Invalid email"}
    end
  end

  defp validate_age(age) when age >= 18, do: {:ok, age}
  defp validate_age(_), do: {:error, "Must be at least 18"}
end

Example 3: Complex - TEA to LiveView Migration

Elm (Todo App):

module Main exposing (main)

import Browser
import Html exposing (..)
import Html.Attributes exposing (..)
import Html.Events exposing (..)

-- MODEL

type alias Model =
    { todos : List Todo
    , input : String
    }

type alias Todo =
    { id : Int
    , text : String
    , completed : Bool
    }

init : () -> ( Model, Cmd Msg )
init _ =
    ( { todos = [], input = "" }, Cmd.none )

-- UPDATE

type Msg
    = UpdateInput String
    | AddTodo
    | ToggleTodo Int
    | RemoveTodo Int

update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        UpdateInput input ->
            ( { model | input = input }, Cmd.none )

        AddTodo ->
            if String.isEmpty model.input then
                ( model, Cmd.none )
            else
                let
                    newTodo =
                        { id = List.length model.todos
                        , text = model.input
                        , completed = False
                        }
                in
                ( { model
                    | todos = model.todos ++ [ newTodo ]
                    , input = ""
                  }
                , Cmd.none
                )

        ToggleTodo id ->
            let
                toggleTodo todo =
                    if todo.id == id then
                        { todo | completed = not todo.completed }
                    else
                        todo
            in
            ( { model | todos = List.map toggleTodo model.todos }, Cmd.none )

        RemoveTodo id ->
            ( { model | todos = List.filter (\t -> t.id /= id) model.todos }
            , Cmd.none
            )

-- VIEW

view : Model -> Html Msg
view model =
    div []
        [ input
            [ type_ "text"
            , placeholder "Add todo"
            , value model.input
            , onInput UpdateInput
            ]
            []
        , button [ onClick AddTodo ] [ text "Add" ]
        , ul [] (List.map viewTodo model.todos)
        ]

viewTodo : Todo -> Html Msg
viewTodo todo =
    li []
        [ input
            [ type_ "checkbox"
            , checked todo.completed
            , onClick (ToggleTodo todo.id)
            ]
            []
        , span
            [ style "text-decoration"
                (if todo.completed then "line-through" else "none")
            ]
            [ text todo.text ]
        , button [ onClick (RemoveTodo todo.id) ] [ text "X" ]
        ]

Elixir (Phoenix LiveView Todo App):

defmodule MyAppWeb.TodoLive do
  use MyAppWeb, :live_view

  # Domain model
  defmodule Todo do
    @type t :: %__MODULE__{
      id: integer(),
      text: String.t(),
      completed: boolean()
    }

    defstruct [:id, :text, :completed]
  end

  # MOUNT (init)
  @impl true
  def mount(_params, _session, socket) do
    {:ok, assign(socket, todos: [], input: "")}
  end

  # HANDLE_EVENT (update)
  @impl true
  def handle_event("update_input", %{"value" => input}, socket) do
    {:noreply, assign(socket, input: input)}
  end

  def handle_event("add_todo", _params, socket) do
    input = socket.assigns.input

    if String.trim(input) == "" do
      {:noreply, socket}
    else
      todos = socket.assigns.todos
      new_todo = %Todo{
        id: length(todos),
        text: input,
        completed: false
      }

      {:noreply, assign(socket, todos: todos ++ [new_todo], input: "")}
    end
  end

  def handle_event("toggle_todo", %{"id" => id}, socket) do
    id = String.to_integer(id)
    todos = Enum.map(socket.assigns.todos, fn todo ->
      if todo.id == id do
        %{todo | completed: !todo.completed}
      else
        todo
      end
    end)

    {:noreply, assign(socket, todos: todos)}
  end

  def handle_event("remove_todo", %{"id" => id}, socket) do
    id = String.to_integer(id)
    todos = Enum.reject(socket.assigns.todos, &(&1.id == id))

    {:noreply, assign(socket, todos: todos)}
  end

  # RENDER (view)
  @impl true
  def render(assigns) do
    ~H"""
    <div>
      <input
        type="text"
        placeholder="Add todo"
        value={@input}
        phx-keyup="update_input"
      />
      <button phx-click="add_todo">Add</button>

      <ul>
        <%= for todo <- @todos do %>
          <li>
            <input
              type="checkbox"
              checked={todo.completed}
              phx-click="toggle_todo"
              phx-value-id={todo.id}
            />
            <span style={"text-decoration: #{if todo.completed, do: "line-through", else: "none"}"}>
              <%= todo.text %>
            </span>
            <button phx-click="remove_todo" phx-value-id={todo.id}>X</button>
          </li>
        <% end %>
      </ul>
    </div>
    """
  end
end

Router configuration:

# In router.ex
scope "/", MyAppWeb do
  pipe_through :browser

  live "/todos", TodoLive
end

See Also

For more examples and patterns, see:

• meta-convert-dev

  - Foundational patterns with cross-language examples

• lang-elm-dev

  - Elm development patterns and TEA

• lang-elixir-dev

  - Elixir development patterns

• lang-elixir-phoenix-dev

  - Advanced Phoenix and LiveView patterns

• lang-elixir-otp-dev

  - OTP patterns for concurrency

Cross-cutting pattern skills:

• patterns-concurrency-dev

  - Compare Elm Cmd/Sub to Elixir processes/GenServer

• patterns-serialization-dev

  - JSON encoding/decoding across languages

• patterns-testing-dev

  - Testing strategies for functional code

References

• Elm Guide - Elm fundamentals and TEA
• Phoenix LiveView Docs - LiveView guide
• Elixir School - Elixir tutorials
• Programming Phoenix LiveView - Book on LiveView patterns