Convert Scala to Erlang

Convert Scala code to idiomatic Erlang. This skill extends meta-convert-dev with Scala-to-Erlang specific type mappings, idiom translations, and tooling for migrating functional JVM code to the BEAM VM and OTP framework.

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: Scala types → Erlang types and records
• Idiom translations: Scala patterns → idiomatic Erlang/OTP
• Error handling: Scala Either/Try/Option → Erlang tuples and let-it-crash
• Concurrency patterns: Scala Future/Akka → Erlang processes and OTP behaviors
• Platform migration: JVM → BEAM VM and OTP
• Memory model shift: JVM shared heap → BEAM per-process heaps

This Skill Does NOT Cover

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

---

Quick Reference

| Scala | Erlang | Notes | |-------|--------|-------| | String | binary() / list() | UTF-8 binary or char list | | Int | integer() | Arbitrary precision in Erlang | | Long | integer() | Same as Int in Erlang | | Double | float() | IEEE 754 double | | Boolean | true / false | Atoms | | Option[T] | {ok, Value} \| error | Tagged tuple | | Some(x) | {ok, X} | Success tuple | | None | error / undefined | Absence | | Either[L,R] | {ok, Value} \| {error, Reason} | Tagged tuple | | Right(x) | {ok, X} | Success | | Left(e) | {error, Reason} | Error | | Try[T] | {ok, Value} \| {error, Reason} | Exception handling | | List[T] | list() | Linked list | | Vector[T] | list() / array() | List or array module | | Array[T] | tuple() / array() | Fixed-size tuple or array | | Map[K,V] | #{K => V} / maps:map() | Map literal or maps module | | Set[T] | sets:set() / ordsets | Sets module | | case class | -record(name, {...}) | Record definition | | sealed trait | Tagged tuples | Discriminated union | | Future[T] | pid() / gen_server | Lightweight process | | object | -module(name). | Singleton as module |

When Converting Code

1. Analyze source thoroughly before writing target
2. Map types first - create type equivalence table
3. Preserve semantics over syntax similarity
4. Adopt Erlang/OTP idioms - don't write "Scala code in Erlang syntax"
5. Embrace let-it-crash - replace defensive programming with supervision
6. Handle edge cases - null safety, error paths, process lifecycle
7. Test equivalence - same inputs → same outputs

---

Type System Mapping

Primitive Types

| Scala | Erlang | Notes | |-------|--------|-------| | String | binary() | UTF-8 binary (most common): <<"Hello">> | | String | string() | Character list (for compatibility): "Hello" | | Int | integer() | 32-bit in Scala, arbitrary precision in Erlang | | Long | integer() | 64-bit in Scala, arbitrary precision in Erlang | | Short | integer() | 16-bit in Scala, arbitrary precision in Erlang | | Byte | integer() | 8-bit in Scala, 0-255 in Erlang | | Double | float() | IEEE 754 double precision | | Float | float() | IEEE 754 single in Scala, double in Erlang | | Boolean | true / false | Atoms (lowercase) | | Char | integer() | Unicode codepoint | | Unit | ok | Atom representing success | | Any | any() / term() | Any Erlang term | | Nothing | N/A | Bottom type, no Erlang equivalent |

Option and Either Types

| Scala | Erlang | Notes | |-------|--------|-------| | None | undefined / error | Atom for absence | | Some(x) | {ok, X} | Tagged tuple for presence | | Option[T] | {ok, Value} \| error \| undefined | Common pattern | | Right(x) | {ok, X} | Success tuple | | Left(e) | {error, Reason} | Error tuple with reason | | Either[L,R] | {ok, Value} \| {error, Reason} | Standard error pattern | | Success(x) | {ok, X} | Try success | | Failure(e) | {error, Reason} | Try failure | | Try[T] | {ok, Value} \| {error, Reason} | Exception handling |

Collection Types

| Scala | Erlang | Notes | |-------|--------|-------| | List[T] | list() | Linked list: [1, 2, 3] | | Vector[T] | list() | No direct equivalent, use list | | Array[T] | tuple() | Fixed-size: {1, 2, 3} | | Array[T] | array:array() | Mutable array module | | Seq[T] | list() | Generic sequence → list | | LazyList[T] | Process-based stream | Stream via gen_server | | Map[K,V] | #{K => V} | Map literal (Erlang 17+) | | Map[K,V] | dict:dict() | Legacy dict module | | Set[T] | sets:set() | Unordered set | | Set[T] | ordsets:ordset() | Ordered set (list-based) | | (A, B) (tuple) | {A, B} | Tuple literal | | (A, B, C) | {A, B, C} | N-tuple | | Range | lists:seq(Start, End) | Sequence generation |

Case Classes and Sealed Traits

| Scala | Erlang | Notes | |-------|--------|-------| | case class Person(name: String, age: Int) | -record(person, {name :: binary(), age :: integer()}). | Record definition | | Person("Alice", 30) | #person{name = <<"Alice">>, age = 30} | Record creation | | person.name | Person#person.name | Field access | | person.copy(age = 31) | Person#person{age = 31} | Record update | | sealed trait Shape | Tagged tuples | Discriminated union | | case class Circle(r: Double) extends Shape | {circle, Radius} | Tagged tuple variant | | case class Rectangle(w: Double, h: Double) extends Shape | {rectangle, Width, Height} | Tagged tuple variant | | case object Empty extends Shape | empty | Atom for singleton |

Function Types

| Scala | Erlang | Notes | |-------|--------|-------| | A => B | fun((A) -> B) | Anonymous function | | (A, B) => C | fun((A, B) -> C) | Multi-param function | | A => B => C | fun((A) -> fun((B) -> C) end end) | Curried (uncommon in Erlang) | | Function1[A,B] | fun((A) -> B) | Function type | | () => A | fun(() -> A) | Nullary function | | A => Unit | fun((A) -> ok) | Side-effect function |

Generic Types

| Scala | Erlang | Notes | |-------|--------|-------| | [T] | term() | Any type (runtime polymorphism) | | List[T] | list(T) | Parameterized type spec | | Option[T] | {ok, T} \| error | Type spec pattern | | Either[L,R] | {ok, R} \| {error, L} | Type spec pattern | | Type bound T <: Upper | Guard clause | when is_record(X, name) | | Type bound T >: Lower | N/A | No lower bounds in Erlang |

---

Idiom Translation

Pattern 1: Option Handling

Scala:

def findUser(id: String): Option[User] =
  users.find(_.id == id)

val name = findUser("123")
  .map(_.name)
  .getOrElse("Unknown")

Erlang:

-spec find_user(binary()) -> {ok, user()} | error.
find_user(Id) ->
    case lists:search(fun(U) -> maps:get(id, U) =:= Id end, users()) of
        {value, User} -> {ok, User};
        false -> error
    end.

get_name(UserId) ->
    case find_user(UserId) of
        {ok, User} -> maps:get(name, User);
        error -> <<"Unknown">>
    end.

Why this translation:

• Scala's Option.map becomes pattern matching in Erlang
• getOrElse becomes the error clause in case expression
• Erlang uses {ok, Value} | error tuples instead of Some/None
• Type specs replace Scala type annotations

Pattern 2: Either-Based Error Handling

Scala:

sealed trait Error
case object DivisionByZero extends Error
case class InvalidInput(msg: String) extends Error

def divide(x: Double, y: Double): Either[Error, Double] =
  if (y == 0.0) Left(DivisionByZero)
  else Right(x / y)

val result = for {
  a <- divide(10.0, 2.0)
  b <- divide(20.0, 4.0)
  c <- divide(a, b)
} yield c

Erlang:

-type error_reason() :: division_by_zero | {invalid_input, binary()}.

-spec divide(float(), float()) -> {ok, float()} | {error, error_reason()}.
divide(_X, 0.0) ->
    {error, division_by_zero};
divide(X, Y) ->
    {ok, X / Y}.

-spec calculate() -> {ok, float()} | {error, error_reason()}.
calculate() ->
    case divide(10.0, 2.0) of
        {ok, A} ->
            case divide(20.0, 4.0) of
                {ok, B} ->
                    divide(A, B);
                {error, Reason} -> {error, Reason}
            end;
        {error, Reason} -> {error, Reason}
    end.

Why this translation:

• Scala for-comprehensions become nested case statements
• Either[L,R] maps to {ok, Value} | {error, Reason} tuples
• Sealed traits become atoms or tagged tuples
• Pattern matching on error tuples replaces monadic bind

Pattern 3: List Processing

Scala:

val result = items
  .filter(_.active)
  .map(_.value)
  .sum

Erlang:

calculate_result(Items) ->
    lists:foldl(
        fun(X, Acc) -> Acc + X end,
        0,
        [maps:get(value, X) || X <- Items, maps:get(active, X)]
    ).

% Alternative: using lists module functions
calculate_result_alt(Items) ->
    Active = lists:filter(fun(X) -> maps:get(active, X) end, Items),
    Values = lists:map(fun(X) -> maps:get(value, X) end, Active),
    lists:sum(Values).

Why this translation:

• Scala method chaining becomes list comprehension or nested function calls
• List comprehension is more idiomatic for filter+map in Erlang
• lists:sum/1 directly replaces .sum
• Both approaches are valid; comprehension is more concise

Pattern 4: Case Class Pattern Matching

Scala:

case class Person(firstName: String, lastName: String, age: Int)

def getFullName(person: Person): String = person match {
  case Person(first, last, _) => s"$first $last"
}

def isAdult(person: Person): Boolean = person match {
  case Person(_, _, age) if age >= 18 => true
  case _ => false
}

Erlang:

-record(person, {
    first_name :: binary(),
    last_name :: binary(),
    age :: integer()
}).

get_full_name(#person{first_name = First, last_name = Last}) ->
    <<First/binary, " ", Last/binary>>.

is_adult(#person{age = Age}) when Age >= 18 ->
    true;
is_adult(_) ->
    false.

Why this translation:

• Scala case class patterns map to Erlang record patterns
• Guards (when) work similarly in both languages
• Scala string interpolation becomes binary concatenation
• Function clauses with pattern matching replace match expressions

Pattern 5: Sealed Trait / ADT

Scala:

sealed trait Result[+T]
case class Success[T](value: T) extends Result[T]
case class Failure(error: String) extends Result[Nothing]
case object Pending extends Result[Nothing]

def process[T](result: Result[T]): String = result match {
  case Success(value) => s"Got: $value"
  case Failure(error) => s"Error: $error"
  case Pending => "Still waiting..."
}

Erlang:

-type result(T) :: {success, T} | {failure, binary()} | pending.

-spec process(result(term())) -> binary().
process({success, Value}) ->
    iolist_to_binary(io_lib:format("Got: ~p", [Value]));
process({failure, Error}) ->
    <<"Error: ", Error/binary>>;
process(pending) ->
    <<"Still waiting...">>.

Why this translation:

• Sealed traits become tagged tuples or atoms
• Case objects become atoms
• Pattern matching translates directly
• Type parameters in Scala become type variables in specs

Pattern 6: Singleton Object

Scala:

object MathUtils {
  val PI = 3.14159

  def square(x: Int): Int = x * x

  def cube(x: Int): Int = x * x * x
}

// Usage
val result = MathUtils.square(5)

Erlang:

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

-define(PI, 3.14159).

square(X) -> X * X.

cube(X) -> X * X * X.

% Usage
Result = math_utils:square(5).

Why this translation:

• Scala objects become Erlang modules
• Public methods become exported functions
• Constants become macros or module attributes
• Fully qualified calls use module:function syntax

---

Paradigm Translation

Mental Model Shift: JVM → BEAM

| Scala Concept | Erlang Approach | Key Insight | |---------------|-----------------|-------------| | Shared mutable state | Isolated process state | Each process has private memory | | Class with methods | Record + module functions | Data and behavior separated | | Inheritance | Protocol implementation | Favor behaviors over hierarchies | | Thread pool | Lightweight processes | Millions of processes, not threads | | Synchronized blocks | Message passing | No shared memory, communicate via messages | | Exception handling | Let-it-crash + supervision | Failures are isolated and handled by supervisors | | Static typing | Dynamic with dialyzer | Runtime flexibility with static analysis |

Concurrency Mental Model

| Scala Pattern | Erlang Pattern | Conceptual Translation | |---------------|----------------|------------------------| | Future[T] | spawn/1 + message passing | Async computation → lightweight process | | Promise[T] | Process mailbox | Future completion → message receipt | | Await.result | receive ... end | Blocking wait → selective receive | | Akka Actor | gen_server behavior | Stateful actor → OTP behavior | | Akka receive | handle_call/handle_cast | Message handling → callback functions | | Akka Supervisor | OTP supervisor | Fault tolerance → supervision tree | | ExecutionContext | Scheduler | Thread pool → BEAM scheduler | | Thread-safe collections | Process dictionary / ETS | Shared state → process-local or ETS |

---

Error Handling

Scala Try/Either → Erlang Tuples and Let-it-Crash

Scala defensive style:

def parseAndProcess(input: String): Try[Int] = Try {
  val num = input.toInt
  if (num < 0) throw new IllegalArgumentException("Negative")
  num * 2
}

val result = parseAndProcess("42") match {
  case Success(value) => println(s"Result: $value")
  case Failure(ex) => println(s"Error: ${ex.getMessage}")
}

Erlang let-it-crash style:

-spec parse_and_process(binary()) -> integer().
parse_and_process(Input) ->
    Num = binary_to_integer(Input),
    true = Num >= 0,  % Crashes if false
    Num * 2.

% Caller can catch or let supervisor handle
-spec safe_parse_and_process(binary()) -> {ok, integer()} | {error, term()}.
safe_parse_and_process(Input) ->
    try
        {ok, parse_and_process(Input)}
    catch
        _:Reason -> {error, Reason}
    end.

Why this translation:

• Erlang prefers crashing over defensive checks
• Supervisors restart failed processes
• Use {ok, Value} | {error, Reason} for expected errors
• Let unexpected errors crash for debugging clarity

Error Propagation Patterns

| Scala Pattern | Erlang Pattern | Notes | |---------------|----------------|-------| | Try { ... } | try ... catch | Exception handling | | .recover { case ... } | catch clauses | Error recovery | | Either.flatMap | Nested case | Error propagation | | Throwing exceptions | throw/exit/error | Rare in idiomatic Erlang | | Custom exception classes | Atoms or tuples | Error reasons as atoms | | Stack trace capture | erlang:get_stacktrace() | For debugging |

---

Concurrency Patterns

Scala Future → Erlang Process

Scala:

import scala.concurrent.{Future, ExecutionContext}
import ExecutionContext.Implicits.global

def fetchData(id: String): Future[Data] = Future {
  // Simulate async operation
  Thread.sleep(1000)
  Data(id, "result")
}

val result = for {
  data1 <- fetchData("1")
  data2 <- fetchData("2")
} yield combine(data1, data2)

result.onComplete {
  case Success(combined) => println(combined)
  case Failure(ex) => println(s"Error: $ex")
}

Erlang:

-spec fetch_data(binary()) -> data().
fetch_data(Id) ->
    timer:sleep(1000),
    #{id => Id, result => <<"result">>}.

-spec async_fetch() -> pid().
async_fetch() ->
    Parent = self(),
    spawn(fun() ->
        Data1 = fetch_data(<<"1">>),
        Data2 = fetch_data(<<"2">>),
        Combined = combine(Data1, Data2),
        Parent ! {result, Combined}
    end).

% Usage
Pid = async_fetch(),
receive
    {result, Combined} -> io:format("~p~n", [Combined])
after 5000 ->
    io:format("Timeout~n")
end.

Why this translation:

• Futures become spawned processes
• onComplete becomes receive pattern matching
• Sequential async (for-comprehension) becomes sequential process code
• Timeout handling is explicit in Erlang

Akka Actor → gen_server

Scala (Akka):

import akka.actor.{Actor, ActorRef, Props}

case class Get(key: String)
case class Put(key: String, value: String)

class KeyValueStore extends Actor {
  private var store = Map.empty[String, String]

  def receive: Receive = {
    case Get(key) =>
      sender() ! store.get(key)

    case Put(key, value) =>
      store = store + (key -> value)
      sender() ! "OK"
  }
}

// Usage
val store = system.actorOf(Props[KeyValueStore])
store ! Put("name", "Alice")
store ! Get("name")

Erlang (gen_server):

-module(kv_store).
-behaviour(gen_server).

-export([start_link/0, get/1, put/2]).
-export([init/1, handle_call/3, handle_cast/2, terminate/2, code_change/3]).

-record(state, {store = #{} :: map()}).

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

get(Key) ->
    gen_server:call(?MODULE, {get, Key}).

put(Key, Value) ->
    gen_server:call(?MODULE, {put, Key, Value}).

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

handle_call({get, Key}, _From, State = #state{store = Store}) ->
    Result = maps:get(Key, Store, undefined),
    {reply, Result, State};

handle_call({put, Key, Value}, _From, State = #state{store = Store}) ->
    NewStore = Store#{Key => Value},
    {reply, ok, State#state{store = NewStore}}.

handle_cast(_Msg, State) ->
    {noreply, State}.

terminate(_Reason, _State) ->
    ok.

code_change(_OldVsn, State, _Extra) ->
    {ok, State}.

Why this translation:

• Akka actors map to gen_server behaviors
• receive block becomes handle_call/handle_cast callbacks
• sender() is implicit in gen_server's From parameter
• State management is explicit in callback return tuples
• OTP provides more structure than raw Akka actors

---

Module and Package Structure

Scala Package → Erlang Module

Scala:

package com.example.myapp

object UserService {
  def createUser(name: String): User = ???
  def deleteUser(id: Int): Unit = ???
}

Erlang:

-module(user_service).
-export([create_user/1, delete_user/1]).

create_user(Name) ->
    % implementation
    ok.

delete_user(Id) ->
    % implementation
    ok.

Translation notes:

• Scala packages become application structure (apps/src directories)
• Scala objects become modules
• Package imports become module calls
• No nested modules in Erlang (flat namespace)

---

Common Pitfalls

1. Overusing exceptions: Erlang prefers let-it-crash for unexpected errors and {ok, Value} | {error, Reason} for expected errors. Don't translate every Try to try...catch.

2. Shared mutable state: Scala's var and mutable collections don't translate directly. Use process state or ETS tables instead.

3. Type erasure issues: Scala's generic types are erased at runtime. Erlang is dynamically typed, but Dialyzer type specs help catch errors.

4. Numeric precision: Scala's Int is 32-bit, but Erlang's integer() is arbitrary precision. Document overflow assumptions.

5. String encoding: Scala strings are UTF-16; Erlang binaries are UTF-8. Use <<"binary">> syntax for UTF-8 strings.

6. Null handling: Scala has null (avoid it), None, and Option. Erlang uses undefined, error, or {ok, Value}. Be consistent.

7. Currying: Scala's curried functions are uncommon in Erlang. Flatten to multi-argument functions.

8. Implicits: Scala's implicit parameters and conversions have no Erlang equivalent. Make dependencies explicit.

9. Case object equality: Scala case objects use reference equality. Erlang atoms use value equality.

10. Pattern match exhaustiveness: Scala's compiler checks exhaustiveness; Erlang/Dialyzer warns but doesn't enforce. Add catch-all clauses.

---

Limitations

Coverage Gaps

| Pillar | Scala Skill | Erlang Skill | Mitigation | |--------|-------------|--------------|------------| | Module | ~ | ✓ | Scala packages explained in context | | Error | ✓ | ✓ | Full coverage | | Concurrency | ✓ | ✓ | Full coverage | | Metaprogramming | ~ | ✓ | Scala macros mentioned where relevant | | Zero/Default | ~ | ✓ | Option/None covered in idioms | | Serialization | ~ | ✓ | Refer to patterns-serialization-dev | | Build | ✓ | ✓ | Full coverage | | Testing | ✓ | ✓ | Full coverage |

Combined Score: 13.5/16 (Good - proceed with pattern skill references)

Known Limitations

1. Serialization: This skill has limited guidance on JSON/serialization libraries because lang-scala-dev lacks dedicated serialization coverage. Refer to patterns-serialization-dev for JSON handling patterns.

2. Metaprogramming: Scala macros and compile-time metaprogramming have limited coverage. Erlang macros and parse transforms are covered in lang-erlang-dev.

3. Module systems: Scala's package objects and imports are not fully covered. Module structure patterns are provided in context.

External Resources Used

| Resource | What It Provided | Reliability | |----------|------------------|-------------| | Scala official docs | Type system, collections API | High | | Erlang official docs | OTP behaviors, gen_server patterns | High | | lang-scala-dev skill | Scala fundamentals, concurrency | High | | lang-erlang-dev skill | Erlang patterns, OTP | High | | convert-erlang-scala | Reverse conversion insights | High |

---

Tooling

| Tool | Purpose | Notes | |------|---------|-------| | rebar3 | Erlang build tool | Successor to rebar, standard for modern Erlang | | Dialyzer | Static analysis | Catches type errors despite dynamic typing | | EUnit | Unit testing | Built-in test framework | | Common Test | Integration testing | OTP's comprehensive test framework | | Observer | Live system inspection | GUI for monitoring processes, ETS, applications | | Recon | Production debugging | Runtime inspection and debugging | | PropEr | Property-based testing | QuickCheck-like testing for Erlang | | Elvis | Style checker | Erlang linter and style enforcer | | Relx | Release building | Creates production releases | | Hex | Package manager | Erlang/Elixir package registry |

No direct transpilers exist from Scala to Erlang. Manual conversion is required.

---

Examples

Example 1: Simple - Type and Function Translation

Before (Scala):

case class Point(x: Double, y: Double)

def distance(p1: Point, p2: Point): Double = {
  val dx = p2.x - p1.x
  val dy = p2.y - p1.y
  Math.sqrt(dx * dx + dy * dy)
}

val origin = Point(0.0, 0.0)
val point = Point(3.0, 4.0)
val dist = distance(origin, point)  // 5.0

After (Erlang):

-module(geometry).
-export([distance/2]).

-record(point, {x :: float(), y :: float()}).

distance(P1, P2) ->
    Dx = P2#point.x - P1#point.x,
    Dy = P2#point.y - P1#point.y,
    math:sqrt(Dx * Dx + Dy * Dy).

% Usage
Origin = #point{x = 0.0, y = 0.0},
Point = #point{x = 3.0, y = 4.0},
Dist = distance(Origin, Point).  % 5.0

Example 2: Medium - Option and Error Handling

Before (Scala):

sealed trait ValidationError
case class InvalidEmail(email: String) extends ValidationError
case class UserNotFound(id: Int) extends ValidationError

case class User(id: Int, name: String, email: String)

def validateEmail(email: String): Either[ValidationError, String] =
  if (email.contains("@")) Right(email)
  else Left(InvalidEmail(email))

def findUser(id: Int): Option[User] =
  // Simulated database lookup
  if (id == 1) Some(User(1, "Alice", "alice@example.com"))
  else None

def getUserEmail(id: Int): Either[ValidationError, String] = {
  for {
    user <- findUser(id).toRight(UserNotFound(id))
    validEmail <- validateEmail(user.email)
  } yield validEmail
}

// Usage
getUserEmail(1) match {
  case Right(email) => println(s"Email: $email")
  case Left(InvalidEmail(e)) => println(s"Invalid email: $e")
  case Left(UserNotFound(id)) => println(s"User $id not found")
}

After (Erlang):

-module(user_validator).
-export([get_user_email/1]).

-record(user, {id :: integer(), name :: binary(), email :: binary()}).

-type validation_error() ::
    {invalid_email, binary()} |
    {user_not_found, integer()}.

-spec validate_email(binary()) -> {ok, binary()} | {error, validation_error()}.
validate_email(Email) ->
    case binary:match(Email, <<"@">>) of
        {_, _} -> {ok, Email};
        nomatch -> {error, {invalid_email, Email}}
    end.

-spec find_user(integer()) -> {ok, user()} | error.
find_user(1) ->
    {ok, #user{id = 1, name = <<"Alice">>, email = <<"alice@example.com">>}};
find_user(_) ->
    error.

-spec get_user_email(integer()) -> {ok, binary()} | {error, validation_error()}.
get_user_email(Id) ->
    case find_user(Id) of
        {ok, User} ->
            validate_email(User#user.email);
        error ->
            {error, {user_not_found, Id}}
    end.

% Usage
case get_user_email(1) of
    {ok, Email} ->
        io:format("Email: ~s~n", [Email]);
    {error, {invalid_email, E}} ->
        io:format("Invalid email: ~s~n", [E]);
    {error, {user_not_found, Id}} ->
        io:format("User ~p not found~n", [Id])
end.

Example 3: Complex - Actor/Process with State Management

Before (Scala with Akka):

import akka.actor.{Actor, ActorRef, Props}
import scala.collection.mutable

case class Subscribe(topic: String, subscriber: ActorRef)
case class Unsubscribe(topic: String, subscriber: ActorRef)
case class Publish(topic: String, message: String)
case class GetSubscribers(topic: String)

class PubSubBroker extends Actor {
  private val subscriptions = mutable.Map.empty[String, Set[ActorRef]]

  def receive: Receive = {
    case Subscribe(topic, subscriber) =>
      val current = subscriptions.getOrElse(topic, Set.empty)
      subscriptions(topic) = current + subscriber
      sender() ! "Subscribed"

    case Unsubscribe(topic, subscriber) =>
      subscriptions.get(topic).foreach { subs =>
        subscriptions(topic) = subs - subscriber
      }
      sender() ! "Unsubscribed"

    case Publish(topic, message) =>
      subscriptions.get(topic).foreach { subscribers =>
        subscribers.foreach(_ ! message)
      }
      sender() ! "Published"

    case GetSubscribers(topic) =>
      val subs = subscriptions.getOrElse(topic, Set.empty)
      sender() ! subs.size
  }
}

// Usage
val broker = system.actorOf(Props[PubSubBroker], "broker")
broker ! Subscribe("news", subscriberActor)
broker ! Publish("news", "Breaking news!")

After (Erlang with gen_server):

-module(pubsub_broker).
-behaviour(gen_server).

-export([start_link/0, subscribe/2, unsubscribe/2, publish/2, get_subscribers/1]).
-export([init/1, handle_call/3, handle_cast/2, terminate/2, code_change/3]).

-record(state, {
    subscriptions = #{} :: #{binary() => [pid()]}
}).

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

subscribe(Topic, Subscriber) ->
    gen_server:call(?MODULE, {subscribe, Topic, Subscriber}).

unsubscribe(Topic, Subscriber) ->
    gen_server:call(?MODULE, {unsubscribe, Topic, Subscriber}).

publish(Topic, Message) ->
    gen_server:cast(?MODULE, {publish, Topic, Message}).

get_subscribers(Topic) ->
    gen_server:call(?MODULE, {get_subscribers, Topic}).

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

handle_call({subscribe, Topic, Subscriber}, _From, State = #state{subscriptions = Subs}) ->
    Current = maps:get(Topic, Subs, []),
    NewSubs = case lists:member(Subscriber, Current) of
        true -> Subs;
        false -> Subs#{Topic => [Subscriber | Current]}
    end,
    {reply, subscribed, State#state{subscriptions = NewSubs}};

handle_call({unsubscribe, Topic, Subscriber}, _From, State = #state{subscriptions = Subs}) ->
    NewSubs = case maps:get(Topic, Subs, []) of
        [] -> Subs;
        List ->
            Subs#{Topic => lists:delete(Subscriber, List)}
    end,
    {reply, unsubscribed, State#state{subscriptions = NewSubs}};

handle_call({get_subscribers, Topic}, _From, State = #state{subscriptions = Subs}) ->
    Count = length(maps:get(Topic, Subs, [])),
    {reply, Count, State}.

handle_cast({publish, Topic, Message}, State = #state{subscriptions = Subs}) ->
    Subscribers = maps:get(Topic, Subs, []),
    lists:foreach(fun(Sub) -> Sub ! {message, Topic, Message} end, Subscribers),
    {noreply, State}.

terminate(_Reason, _State) ->
    ok.

code_change(_OldVsn, State, _Extra) ->
    {ok, State}.

% Usage
{ok, _Pid} = pubsub_broker:start_link(),
pubsub_broker:subscribe(<<"news">>, self()),
pubsub_broker:publish(<<"news">>, <<"Breaking news!">>),
receive
    {message, <<"news">>, Msg} ->
        io:format("Received: ~s~n", [Msg])
after 5000 ->
    io:format("Timeout~n")
end.

Key differences in this example:

• Akka's mutable Map becomes immutable Map in gen_server state
• sender() is handled implicitly by gen_server's From parameter
• Fire-and-forget messages (!) map to handle_cast
• Request-reply messages map to handle_call
• Supervision and lifecycle are managed by OTP

---

See Also

For more examples and patterns, see:

• meta-convert-dev - Foundational patterns with cross-language examples
• convert-erlang-scala - Reverse conversion (Erlang → Scala)
• convert-fsharp-erlang - Similar functional JVM → BEAM conversion
• lang-scala-dev - Scala development patterns
• lang-erlang-dev - Erlang development patterns

Cross-cutting pattern skills (for areas not fully covered by lang-*-dev):

• patterns-concurrency-dev - Async, channels, actors across languages
• patterns-serialization-dev - JSON, validation across languages
• patterns-metaprogramming-dev - Macros, compile-time code generation