Convert Erlang to Roc

Convert Erlang code to idiomatic Roc. This skill extends meta-convert-dev with Erlang-to-Roc specific type mappings, idiom translations, and architectural patterns for moving from process-based concurrency to pure functional programming.

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: Erlang dynamic types → Roc static types
•Paradigm translation: Process-based concurrency → Pure functional with Tasks
•Idiom translations: OTP patterns → Roc functional patterns
•Error handling: Let-it-crash + supervisors → Result types
•Concurrency: Erlang processes → Roc platform Tasks
•Module system: Erlang modules → Roc platform/application architecture

This Skill Does NOT Cover

•General conversion methodology - see meta-convert-dev
•Erlang language fundamentals - see lang-erlang-dev
•Roc language fundamentals - see lang-roc-dev
•Reverse conversion (Roc → Erlang) - see convert-roc-erlang

Quick Reference

Erlang	Roc	Notes
`atom()`	`[TagName]`	Atoms become tags
`integer()`	`I64` / `U64`	Specify signedness
`float()`	`F64`	64-bit float
`binary()`	`List U8`	Byte sequences
`list()`	`List a`	Homogeneous lists
`tuple()`	`(a, b, c)`	Fixed-size tuples
`map()`	`Dict k v`	Key-value maps
`{ok, Value}`	`Ok(value)`	Success result
`{error, Reason}`	`Err(reason)`	Error result
`pid()`	-	No direct equivalent (use platform)
`fun(() -> T)`	`({} -> T)`	Zero-arg function
`undefined`	`None` in tag union	Optional values

When Converting Code

•Analyze BEAM semantics before writing Roc
•Identify process boundaries - these become platform interactions
•Map dynamic patterns to static types - use tag unions for variants
•Redesign supervision trees - Roc platforms handle failure differently
•Extract pure logic - separate computation from effects
•Test equivalence - verify behavior matches despite different architecture

Paradigm Translation

Mental Model Shift: BEAM Processes → Pure Functions + Platform Tasks

Erlang Concept	Roc Approach	Key Insight
Process with state	Record + functions operating on record	Data and behavior separated, no hidden state
Message passing	Function parameters and results	Explicit data flow, no mailboxes
Spawn process	Platform task	Effects are platform capability, not language feature
gen_server	Pure state machine + platform Task	Business logic pure, I/O delegated to platform
Supervisor	Platform-level concern	Fault tolerance handled by host, not application
Hot code reload	Platform capability	Not a language feature in Roc
Distributed Erlang	Platform networking	Distribution is platform responsibility

Concurrency Mental Model

Erlang Model	Roc Model	Conceptual Translation
Lightweight processes	Platform Tasks	Concurrency is platform capability
Process mailbox	Function composition	Messages become function parameters
Selective receive	Pattern matching on values	Match on data, not messages in mailbox
Process monitoring	Result types	Failure becomes explicit error values
Links and trapping exits	Error propagation with Result	Explicit error handling replaces process signals

Type System Mapping

Primitive Types

Erlang	Roc	Notes
`atom()`	`[Tag]` or `Str`	Atoms as tags for enums, Str for dynamic atoms
`integer()`	`I64`	Default signed 64-bit
`integer()`	`U64`	Unsigned variant
`integer()` (small)	`I32` / `U32`	For smaller values
`integer()` (big)	`I128` / `U128`	For very large values
`float()`	`F64`	64-bit floating point
`boolean()`	`Bool`	Direct mapping
`binary()`	`List U8`	Byte sequence as list
`bitstring()`	`List U8`	Byte-aligned only in Roc
`reference()`	-	No direct equivalent
`pid()`	-	Processes don't exist in Roc
`port()`	-	Platform handles I/O
`fun()`	Function types	See function mappings below

Collection Types

Erlang	Roc	Notes
`list()`	`List a`	Homogeneous lists
`[T]` notation	`List T`	Type-safe, uniform elements
`tuple()`	`(A, B, C)`	Fixed-size tuples
`{A, B, C}`	`(A, B, C)`	Direct structural mapping
`map()`	`Dict k v`	Key-value dictionary
`#{K => V}`	`Dict K V`	Must have Hash + Eq for keys
`sets:set()`	`Set a`	Unique values
`ordsets:set()`	`Set a`	Roc sets are always ordered
`queue:queue()`	`List a`	Use list operations
`array:array()`	`List a`	Lists in Roc are efficient

Composite Types

Erlang	Roc	Notes
`-record(name, {field :: type()})`	`{ field : Type }`	Records become record types
`#name{field = Value}`	`{ field: value }`	Record literals
Tagged tuple `{tag, Value}`	`Tag(value)`	Tags with payloads
Union types (spec)	`[Tag1, Tag2, Tag3]`	Tag unions
`-type name() :: spec.`	`Name : Type`	Type alias
`-opaque name() :: spec.`	Opaque type `Name := Type`	Hidden implementation

Function Types

Erlang	Roc	Notes
`fun(() -> R)`	`({} -> R)`	Zero-argument function
`fun((A) -> R)`	`(A -> R)`	Single argument
`fun((A, B) -> R)`	`(A, B -> R)`	Multiple arguments
`fun((A, ...) -> R)`	-	Roc doesn't support varargs

Error Types

Erlang	Roc	Notes
`{ok, Value}`	`Ok(value)`	Success case
`{error, Reason}`	`Err(reason)`	Error case
`ok` atom	`Ok({})`	Success with no value
`{ok, V} \| {error, R}`	`Result V R`	Result type
Exception throw	`Err` variant	No exceptions, use Result

Idiom Translation

Pattern 1: Simple Function Conversion

Erlang:

erlang

-module(math_utils).
-export([add/2, square/1]).

add(A, B) -> A + B.

square(N) -> N * N.

Roc:

roc

interface MathUtils
    exposes [add, square]
    imports []

add : I64, I64 -> I64
add = \a, b -> a + b

square : I64 -> I64
square = \n -> n * n

Why this translation:

•Erlang modules become Roc interfaces
•Exported functions go in exposes
•Type signatures are inferred but can be explicit
•Function definitions use lambda syntax

Pattern 2: Pattern Matching on Tagged Tuples

Erlang:

erlang

process_result({ok, Data}) ->
    {success, Data};
process_result({error, Reason}) ->
    {failure, Reason};
process_result(unknown) ->
    {failure, unknown_result}.

Roc:

roc

processResult : [Ok Data, Err Reason, Unknown] -> [Success Data, Failure Reason]
processResult = \result ->
    when result is
        Ok(data) -> Success(data)
        Err(reason) -> Failure(reason)
        Unknown -> Failure(UnknownResult)

Why this translation:

•Erlang tagged tuples map to Roc tags
•Pattern matching syntax is similar
•Tag unions make all cases explicit
•Type system ensures exhaustiveness

Pattern 3: List Processing

Erlang:

erlang

sum([]) -> 0;
sum([H|T]) -> H + sum(T).

map(_, []) -> [];
map(F, [H|T]) -> [F(H) | map(F, T)].

filter(_, []) -> [];
filter(Pred, [H|T]) ->
    case Pred(H) of
        true -> [H | filter(Pred, T)];
        false -> filter(Pred, T)
    end.

Roc:

roc

sum : List I64 -> I64
sum = \list ->
    List.walk(list, 0, Num.add)

map : List a, (a -> b) -> List b
map = \list, fn ->
    List.map(list, fn)

filter : List a, (a -> Bool) -> List a
filter = \list, pred ->
    List.keepIf(list, pred)

Why this translation:

•Roc provides built-in list functions
•List.walk is fold/reduce
•Explicit recursion not needed for common operations
•Higher-order functions are idiomatic

Pattern 4: Records to Records

Erlang:

erlang

-record(user, {
    name :: string(),
    age :: integer(),
    email :: string()
}).

create_user(Name, Age, Email) ->
    #user{name=Name, age=Age, email=Email}.

update_age(#user{} = User, NewAge) ->
    User#user{age=NewAge}.

get_name(#user{name=Name}) ->
    Name.

Roc:

roc

User : {
    name : Str,
    age : U32,
    email : Str,
}

createUser : Str, U32, Str -> User
createUser = \name, age, email ->
    { name, age, email }

updateAge : User, U32 -> User
updateAge = \user, newAge ->
    { user & age: newAge }

getName : User -> Str
getName = \{ name } ->
    name

Why this translation:

•Erlang records map directly to Roc records
•Record update syntax is similar (#record{} vs { record & })
•Pattern matching on records works similarly
•Roc records are structural, not nominal

Pattern 5: gen_server State Machine → Pure State Functions

Erlang:

erlang

-module(counter_server).
-behaviour(gen_server).

-export([start_link/0, increment/0, get_count/0]).
-export([init/1, handle_call/3, handle_cast/2]).

start_link() ->
    gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).

increment() ->
    gen_server:cast(?MODULE, increment).

get_count() ->
    gen_server:call(?MODULE, get_count).

init([]) ->
    {ok, 0}.

handle_call(get_count, _From, Count) ->
    {reply, Count, Count}.

handle_cast(increment, Count) ->
    {noreply, Count + 1}.

Roc:

roc

# Pure state machine - no processes
State : I64

init : State
init = 0

increment : State -> State
increment = \count ->
    count + 1

getCount : State -> I64
getCount = \count ->
    count

# If you need effects, use platform Tasks
# Platform would provide state management primitives

Why this translation:

•gen_server becomes pure state functions
•No process lifecycle - just data transformation
•State is explicit parameter and return value
•Effects would be handled by platform, not shown here
•Platform provides concurrency if needed

Pattern 6: Error Handling with Result

Erlang:

erlang

divide(_, 0) ->
    {error, division_by_zero};
divide(A, B) ->
    {ok, A / B}.

safe_divide(A, B) ->
    case divide(A, B) of
        {ok, Result} -> Result;
        {error, _} -> 0
    end.

Roc:

roc

divide : F64, F64 -> Result F64 [DivisionByZero]
divide = \a, b ->
    if b == 0 then
        Err(DivisionByZero)
    else
        Ok(a / b)

safeDivide : F64, F64 -> F64
safeDivide = \a, b ->
    divide(a, b)
    |> Result.withDefault(0)

Why this translation:

•Erlang error tuples map to Roc Result type
•Pattern matching on Result works like case
•Result combinators (withDefault) are idiomatic
•Compile-time exhaustiveness checking

Pattern 7: Optional Values

Erlang:

erlang

find_user(Id, Users) ->
    case lists:keyfind(Id, #user.id, Users) of
        false -> undefined;
        User -> User
    end.

get_email(undefined) -> "no email";
get_email(#user{email=Email}) -> Email.

Roc:

roc

findUser : U64, List User -> [Some User, None]
findUser = \id, users ->
    users
    |> List.findFirst(\user -> user.id == id)
    |> Result.map(Some)
    |> Result.withDefault(None)

getEmail : [Some User, None] -> Str
getEmail = \maybeUser ->
    when maybeUser is
        Some({ email }) -> email
        None -> "no email"

Why this translation:

•Erlang undefined maps to tag union with None
•false from failed search becomes None
•Pattern matching on option types is explicit
•Type system prevents forgetting to handle None case

Pattern 8: List Comprehensions

Erlang:

erlang

squares(List) ->
    [X * X || X <- List].

evens(List) ->
    [X || X <- List, X rem 2 == 0].

pairs(List1, List2) ->
    [{X, Y} || X <- List1, Y <- List2].

Roc:

roc

squares : List I64 -> List I64
squares = \list ->
    List.map(list, \x -> x * x)

evens : List I64 -> List I64
evens = \list ->
    List.keepIf(list, \x -> x % 2 == 0)

pairs : List a, List b -> List (a, b)
pairs = \list1, list2 ->
    List.joinMap(list1, \x ->
        List.map(list2, \y -> (x, y))
    )

Why this translation:

•Comprehensions become map/filter operations
•Nested comprehensions use joinMap (flatMap)
•More verbose but explicit
•Type signatures make intent clear

Concurrency Patterns

Erlang Process Model vs Roc Task Model

Erlang's concurrency is built on lightweight processes with message passing. Roc has no built-in concurrency - it's all platform-provided.

Erlang:

erlang

% Spawn a worker process
Pid = spawn(fun() -> worker_loop() end),

% Send message
Pid ! {self(), work, Data},

% Receive response
receive
    {Pid, result, Result} -> Result
after 5000 ->
    timeout
end.

worker_loop() ->
    receive
        {From, work, Data} ->
            Result = process(Data),
            From ! {self(), result, Result},
            worker_loop();
        stop ->
            ok
    end.

Roc:

roc

# No processes - pure functions operating on data
processWork : Data -> Result
processWork = \data ->
    # Pure computation
    transform(data)

# If concurrent work is needed, platform provides Tasks
# Platform interface might look like:
doWork : Data -> Task Result []
doWork = \data ->
    # Platform handles execution
    Task.fromResult(processWork(data))

# Multiple concurrent tasks (platform-dependent)
doMultipleWork : List Data -> Task (List Result) []
doMultipleWork = \dataList ->
    dataList
    |> List.map(doWork)
    |> Task.sequence  # Platform parallelizes

Why this approach:

•Roc applications don't manage processes
•Concurrency is a platform capability
•Business logic stays pure
•Platform provides Task-based effects

Supervision Trees → Error Handling

Erlang:

erlang

-module(my_supervisor).
-behaviour(supervisor).

init([]) ->
    SupFlags = #{
        strategy => one_for_one,
        intensity => 5,
        period => 60
    },

    ChildSpecs = [
        #{
            id => worker1,
            start => {worker, start_link, []},
            restart => permanent,
            shutdown => 5000,
            type => worker
        }
    ],

    {ok, {SupFlags, ChildSpecs}}.

Roc:

roc

# Roc doesn't have supervision trees
# Instead, errors are explicit via Result types
# Platform handles process-level concerns

# Application code propagates errors explicitly
doWorkflow : Input -> Result Output [WorkerFailed, ValidationFailed]
doWorkflow = \input ->
    validated = validate!(input)
    processed = processData!(validated)
    saved = saveResult!(processed)
    Ok(saved)

# Platform provides retry/recovery if needed
withRetry : Task a err, U32 -> Task a err
withRetry = \task, maxAttempts ->
    # Platform-provided retry logic
    Task.retry(task, maxAttempts)

Why this translation:

•Supervision is platform responsibility, not application code
•Errors are explicit Result values
•No automatic restart - retry is explicit
•Crash recovery happens at platform/host level

Distributed Erlang → Platform Networking

Erlang:

erlang

% Connect to remote node
net_adm:ping('node2@hostname'),

% Spawn on remote node
Pid = spawn('node2@hostname', worker, loop, []),

% Send to remote process
{worker, 'node2@hostname'} ! Message,

% RPC call
rpc:call('node2@hostname', module, function, [Args]).

Roc:

roc

# No distributed Erlang equivalent
# Platform provides networking as I/O capability

# Hypothetical platform networking API
sendRequest : Str, Request -> Task Response [NetworkErr]
sendRequest = \url, request ->
    # Platform handles HTTP/networking
    Http.post(url, request)

# Distributed work requires platform support
# Not a language feature

Why this approach:

•Distribution is platform capability, not language
•No node clustering built-in
•Network calls are explicit I/O via Tasks
•Platform defines distribution model

Error Handling

Let It Crash → Explicit Result Types

Erlang Philosophy:

erlang

% Let it crash - supervisor will restart
process_data(Data) ->
    validate(Data),      % May throw
    transform(Data),     % May throw
    save(Data).         % May throw

Roc Philosophy:

roc

# Make errors explicit with Result types
processData : Data -> Result Success [ValidationErr, TransformErr, SaveErr]
processData = \data ->
    validated = validate!(data)
    transformed = transform!(validated)
    saved = save!(transformed)
    Ok(saved)

Key Differences:

•Erlang: Crash and restart via supervisor
•Roc: Explicit error propagation via Result
•Erlang: Fault tolerance via process isolation
•Roc: Fault tolerance via platform (if needed)

Error Pattern Translation

Erlang Pattern	Roc Pattern	Notes
`throw(Error)`	`Err(error)`	No exceptions, use Result
`exit(Reason)`	`Err(reason)`	Process exit becomes error value
`error(Reason)`	`Err(reason)`	Runtime error becomes Result
`try...catch`	`when result is Ok/Err`	Pattern match on Result
Supervisor restart	Platform responsibility	Not in application code
Process link	Error propagation via Result	No process links
Monitor/demonitor	-	No monitoring in Roc

Module System

Erlang Module → Roc Interface

Erlang:

erlang

-module(calculator).
-export([add/2, subtract/2]).
-export_type([result/0]).

-type result() :: {ok, number()} | {error, atom()}.

add(A, B) -> {ok, A + B}.
subtract(A, B) -> {ok, A - B}.

Roc:

roc

interface Calculator
    exposes [Result, add, subtract]
    imports []

Result : [Ok F64, Err [InvalidInput]]

add : F64, F64 -> Result
add = \a, b -> Ok(a + b)

subtract : F64, F64 -> Result
subtract = \a, b -> Ok(a - b)

Why this translation:

•-module becomes interface
•-export becomes exposes
•-export_type types also go in exposes
•Type definitions use Roc syntax

Application Structure

Erlang Application:

code

my_app/
├── src/
│   ├── my_app.erl
│   ├── my_app_sup.erl
│   └── my_worker.erl
├── include/
│   └── my_app.hrl
└── ebin/

Roc Application:

code

my-app/
├── main.roc          # Entry point
├── Worker.roc        # Worker module
└── Types.roc         # Shared types

Key Differences:

•Roc: Single entry point (main.roc)
•No supervision tree in application code
•Platform provides I/O capabilities
•Simpler directory structure

Platform Architecture

OTP Application → Roc Application + Platform

Erlang OTP Application:

erlang

% Application behavior
-module(my_app).
-behaviour(application).

start(_Type, _Args) ->
    my_app_sup:start_link().

stop(_State) ->
    ok.

Roc Application:

roc

app [main] {
    pf: platform "https://github.com/roc-lang/basic-cli/..."
}

import pf.Stdout
import pf.Task exposing [Task]

main : Task {} []
main =
    Stdout.line!("Hello, World!")

Why this approach:

•Roc separates platform (I/O) from application (logic)
•Platform provides lifecycle, not application
•No application behavior callback
•Platform handles startup/shutdown

BEAM Runtime → Platform + Host

code

┌─────────────────────────────────┐
│   Erlang on BEAM                │
│                                 │
│  • Processes                    │
│  • Schedulers                   │
│  • Message passing              │
│  • Hot code reload              │
│  • Distribution                 │
└─────────────────────────────────┘

             ⬇

┌─────────────────────────────────┐
│   Roc Application (Pure)        │
│                                 │
│  • Pure functions               │
│  • Data transformations         │
│  • Business logic               │
└──────────────┬──────────────────┘
               │
┌──────────────▼──────────────────┐
│   Platform + Host               │
│                                 │
│  • Task execution               │
│  • I/O operations               │
│  • Concurrency (if provided)    │
│  • Memory management            │
└─────────────────────────────────┘

Testing Strategy

EUnit → Roc expect

Erlang EUnit:

erlang

-module(calculator_tests).
-include_lib("eunit/include/eunit.hrl").

add_test() ->
    ?assertEqual({ok, 5}, calculator:add(2, 3)).

subtract_test() ->
    ?assertEqual({ok, 1}, calculator:subtract(3, 2)).

Roc expect:

roc

# Inline tests with expect
add : I64, I64 -> I64
add = \a, b -> a + b

expect add(2, 3) == 5
expect add(0, 0) == 0
expect add(-1, 1) == 0

# Top-level expects run with `roc test`
expect
    result = add(2, 3)
    result == 5

Why this translation:

•Roc uses inline expect statements
•No test framework needed
•Tests live with code
•Run with roc test

Property-Based Testing

Erlang PropEr:

erlang

prop_reverse_twice() ->
    ?FORALL(List, list(integer()),
            lists:reverse(lists:reverse(List)) =:= List).

Roc:

roc

# Roc doesn't have built-in property testing yet
# For now, write explicit test cases

expect
    list = [1, 2, 3, 4, 5]
    reversed = List.reverse(list)
    doubleReversed = List.reverse(reversed)
    doubleReversed == list

# Future: property testing libraries may emerge

Common Pitfalls

•
Trying to translate processes directly: Erlang processes don't exist in Roc. Redesign around pure functions and platform Tasks.
•
Missing the paradigm shift: Erlang is concurrent-first, Roc is pure-first. Separate computation from effects.
•
Assuming mutable state: Erlang has process state, Roc uses immutable data. State changes are new values.
•
Ignoring the platform boundary: In Roc, all I/O goes through the platform. Don't expect direct system calls.
•
Translating supervisors: Supervision is platform-level. Don't try to implement restart logic in application code.
•
Dynamic typing habits: Erlang allows any(), Roc requires explicit types. Use tag unions for variants.
•
Hot code reload: Erlang supports this, Roc doesn't. Not a conversion concern.
•
Binary pattern matching: Erlang's binary patterns are powerful, Roc works with List U8. May need rethinking.
•
Distributed Erlang features: node clustering, global registry, etc. - these are BEAM features, not Roc capabilities.
•
Atom literals everywhere: Erlang uses atoms liberally, Roc needs explicit tag unions or strings.

Tooling

Purpose	Erlang	Roc	Notes
Build tool	rebar3, mix	`roc` CLI	Roc has single tool
Package manager	hex.pm	Platform URLs	No package registry yet
Testing	EUnit, CT, PropEr	`roc test`	Built-in testing
REPL	`erl` shell	-	No Roc REPL yet
Formatter	erlfmt	`roc format`	Automatic formatting
Documentation	EDoc	Comments	No doc tool yet
Debugger	debugger	-	No debugger yet
Profiling	fprof, eprof	-	Platform-specific

Examples

Example 1: Simple - Function with Pattern Matching

Before (Erlang):

erlang

-module(color).
-export([to_string/1]).

to_string(red) -> "Red";
to_string(green) -> "Green";
to_string(blue) -> "Blue";
to_string({rgb, R, G, B}) ->
    io_lib:format("RGB(~p, ~p, ~p)", [R, G, B]).

After (Roc):

roc

interface Color
    exposes [Color, toString]
    imports []

Color : [Red, Green, Blue, Rgb U8 U8 U8]

toString : Color -> Str
toString = \color ->
    when color is
        Red -> "Red"
        Green -> "Green"
        Blue -> "Blue"
        Rgb(r, g, b) -> "RGB(\(Num.toStr(r)), \(Num.toStr(g)), \(Num.toStr(b)))"

Example 2: Medium - State Machine with Error Handling

Before (Erlang):

erlang

-module(bank_account).
-export([new/0, deposit/2, withdraw/2, balance/1]).

-record(account, {
    balance = 0 :: integer()
}).

new() -> #account{}.

deposit(#account{balance=Balance} = Account, Amount) when Amount > 0 ->
    {ok, Account#account{balance=Balance + Amount}};
deposit(_, _) ->
    {error, invalid_amount}.

withdraw(#account{balance=Balance} = Account, Amount)
        when Amount > 0, Amount =< Balance ->
    {ok, Account#account{balance=Balance - Amount}};
withdraw(#account{balance=Balance}, Amount) when Amount > Balance ->
    {error, insufficient_funds};
withdraw(_, _) ->
    {error, invalid_amount}.

balance(#account{balance=Balance}) ->
    Balance.

After (Roc):

roc

interface BankAccount
    exposes [Account, new, deposit, withdraw, balance]
    imports []

Account : { balance : U64 }

new : Account
new = { balance: 0 }

deposit : Account, U64 -> Result Account [InvalidAmount]
deposit = \account, amount ->
    if amount > 0 then
        Ok({ account & balance: account.balance + amount })
    else
        Err(InvalidAmount)

withdraw : Account, U64 -> Result Account [InvalidAmount, InsufficientFunds]
withdraw = \account, amount ->
    if amount == 0 then
        Err(InvalidAmount)
    else if amount > account.balance then
        Err(InsufficientFunds)
    else
        Ok({ account & balance: account.balance - amount })

balance : Account -> U64
balance = \account ->
    account.balance

Example 3: Complex - gen_server Reimagined as Pure State Machine

Before (Erlang):

erlang

-module(task_queue).
-behaviour(gen_server).

-export([start_link/0, add_task/1, get_next/0, count/0]).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2]).

-record(state, {
    tasks = [] :: list(),
    processed = 0 :: integer()
}).

%% API
start_link() ->
    gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).

add_task(Task) ->
    gen_server:cast(?MODULE, {add, Task}).

get_next() ->
    gen_server:call(?MODULE, get_next).

count() ->
    gen_server:call(?MODULE, count).

%% Callbacks
init([]) ->
    {ok, #state{}}.

handle_call(get_next, _From, #state{tasks=[]} = State) ->
    {reply, empty, State};
handle_call(get_next, _From, #state{tasks=[H|T], processed=P} = State) ->
    NewState = State#state{tasks=T, processed=P+1},
    {reply, {ok, H}, NewState};
handle_call(count, _From, #state{tasks=Tasks, processed=P} = State) ->
    {reply, {length(Tasks), P}, State}.

handle_cast({add, Task}, #state{tasks=Tasks} = State) ->
    NewState = State#state{tasks=Tasks ++ [Task]},
    {noreply, NewState}.

handle_info(_Info, State) ->
    {noreply, State}.

terminate(_Reason, _State) ->
    ok.

After (Roc):

roc

interface TaskQueue
    exposes [Queue, empty, addTask, getNext, count]
    imports []

Queue task : {
    tasks : List task,
    processed : U64,
}

empty : Queue task
empty = {
    tasks: [],
    processed: 0,
}

addTask : Queue task, task -> Queue task
addTask = \queue, task ->
    { queue & tasks: List.append(queue.tasks, task) }

getNext : Queue task -> Result (Queue task, task) [Empty]
getNext = \queue ->
    when queue.tasks is
        [] -> Err(Empty)
        [first, ..rest] ->
            newQueue = {
                tasks: rest,
                processed: queue.processed + 1,
            }
            Ok((newQueue, first))

count : Queue task -> { pending : U64, processed : U64 }
count = \queue ->
    {
        pending: List.len(queue.tasks),
        processed: queue.processed,
    }

# Usage example:
expect
    queue = empty
    queue1 = addTask(queue, "task1")
    queue2 = addTask(queue1, "task2")

    result = getNext(queue2)
    when result is
        Ok((queue3, task)) ->
            task == "task1" && count(queue3).pending == 1
        Err(Empty) -> Bool.false

# Note: This is a pure data structure
# If you need concurrent access, platform provides that capability

Limitations

Areas Where Direct Translation Is Difficult

•
Hot Code Reload: Erlang's live code update has no Roc equivalent. Requires restart.
•
Distributed Features: BEAM's clustering, global names, distributed process groups - not available in Roc.
•
Process Isolation: Erlang's per-process memory isolation doesn't map to Roc's data structures.
•
Selective Receive: Erlang's mailbox pattern matching doesn't exist - Roc uses function parameters.
•
Binary Pattern Matching: Erlang's bit-level patterns are more powerful than Roc's List U8.
•
Dynamic Code: Erlang's ability to load/call modules dynamically doesn't exist in statically-typed Roc.
•
Process Monitoring: Links, monitors, trapping exits - these are BEAM features, not portable to Roc.

Working Around Limitations

•Instead of hot reload: Design for fast restart or use platform-provided mechanism
•Instead of distribution: Use explicit networking via platform HTTP/TCP
•Instead of processes: Use pure functions + platform Tasks
•Instead of selective receive: Structure data for pattern matching
•Instead of binary patterns: Work with List U8 and helper functions
•Instead of dynamic code: Use tag unions for known variants
•Instead of process monitoring: Use Result types for error handling

Convert Erlang to Roc

This Skill Extends

This Skill Adds

This Skill Does NOT Cover

Quick Reference

When Converting Code

Paradigm Translation

Mental Model Shift: BEAM Processes → Pure Functions + Platform Tasks

Concurrency Mental Model

Type System Mapping

Primitive Types

Collection Types

Composite Types

Function Types

Error Types

Idiom Translation

Pattern 1: Simple Function Conversion

Pattern 2: Pattern Matching on Tagged Tuples

Pattern 3: List Processing

Pattern 4: Records to Records

Pattern 5: gen_server State Machine → Pure State Functions

Pattern 6: Error Handling with Result

Pattern 7: Optional Values

Pattern 8: List Comprehensions

Concurrency Patterns

Erlang Process Model vs Roc Task Model

Supervision Trees → Error Handling

Distributed Erlang → Platform Networking

Error Handling

Let It Crash → Explicit Result Types

Error Pattern Translation

Module System

Erlang Module → Roc Interface

Application Structure

Platform Architecture

OTP Application → Roc Application + Platform

BEAM Runtime → Platform + Host

Testing Strategy

EUnit → Roc expect

Property-Based Testing

Common Pitfalls

Tooling

Examples

Example 1: Simple - Function with Pattern Matching

Example 2: Medium - State Machine with Error Handling

Example 3: Complex - gen_server Reimagined as Pure State Machine

Limitations

Areas Where Direct Translation Is Difficult

Working Around Limitations

See Also