Erlang.CodeCompared.To/Pony

Erlang prints with io:format/1 and the ~n directive for the newline. Every Pony program's entry point is actor Main with a new create(env: Env) constructor — env.out.print appends the newline for you, the way io:format's ~n does explicitly.

Erlang's ~p directive renders any term for humans automatically. Pony has no universal "pretty print" — every value must be explicitly converted with .string() and concatenated by hand, since Pony has no runtime reflection over arbitrary types the way Erlang's term representation allows.

Erlang has no compile-time type checking at all. Pony is fully statically typed — every parameter and return type is checked before the program ever runs, and Pony additionally checks that every reference capability is used safely, catching entire categories of concurrency bugs Erlang can only ever discover at runtime.

This is the strongest headline parallel on the whole site: both languages put the actor at the absolute center of the language, not layered on top as a library the way Scala's Akka or F#'s MailboxProcessor are. Erlang's spawn/1 creates a process from a fun; Pony's actor Greeter declares an actor type directly, and let greeter = Greeter instantiates one — conceptually the same act of bringing a new independent unit of concurrency into existence.

Both an Erlang process and a Pony actor process exactly one message at a time, strictly in the order received — this is precisely what makes _count safe to mutate directly inside Counter without any lock, the same way an Erlang process's internal state never needs a mutex. Two increment() calls can never interleave inside one actor.

Calling logger.log(env, "hello") does not run log synchronously — it enqueues a message in Logger's mailbox and returns to the caller immediately, exactly like Erlang's !. The difference is that Pony makes this explicit in the type system: any method declared be is guaranteed async and returns None, where Erlang's ! is just an operator you apply to any Pid, with no type-level distinction from a synchronous call.

A Pony fun is an ordinary, synchronous, value-returning call — the caller waits and gets a result directly, just like calling an Erlang fun from within the same process. Erlang has no separate "async function" concept: everything inside one process is synchronous, and the only asynchronous operation is sending a message with ! to a different process.

This is a genuine shared design decision, not just superficially similar wording: both languages give every concurrent unit (Erlang process / Pony actor) its own private heap, collected independently. Neither language has a global "stop the world" garbage collector pause — one actor's or process's collection never blocks any other, a guarantee most garbage-collected languages (Go, the JVM, .NET) cannot make in the same way.

This is the biggest new concept for an Erlang developer, and the deepest technical difference between the two languages. Erlang guarantees safety by always copying data across a process boundary — there is genuinely no other memory to worry about. Pony instead uses reference capabilities (iso, val, ref, box, tag, trn) to let the compiler prove, at compile time, that a given reference can be safely handed to another actor with zero copying — val above means "globally immutable, therefore safe to share," so Pony can pass even huge structures between actors instantly, something Erlang's copy-everything model cannot do without cost proportional to size.

An iso reference is guaranteed to be the only reference to that data anywhere in the program — closer to Rust's ownership model than anything in Erlang. Erlang has no concept of "the only reference" at all; a value can be bound to any number of variables across any number of processes (as long as it was copied to each), with none of them ever becoming invalid.

Erlang picks a function clause by matching the call against each in order; Pony's match expression works similarly, with | introducing each case and a guard condition attached with if. Pony's syntax needs an explicit bound name (let n': I64) to both bind and guard in one arm — slightly more ceremony than Erlang's bare N when N > 0, but the same underlying idea.

Where Erlang wraps failure in a {error, Reason} tuple the caller must pattern-match, Pony marks a function partial with a trailing ? in its signature — fun apply(x: I64, y: I64): I64 ? — meaning it might raise instead of returning. Calling it requires either another ? (propagating the failure up, close to Rust's ? operator) or a try/else block, as shown, to handle it locally.

This is a real ergonomic gap compared to Erlang: Pony's error is a bare control-flow signal with no attached data at all, where Erlang's {error, Reason} always carries an explanation for free. Modeling "failure with a reason" in Pony means layering your own union type ((I64 | String)) or a small error-data class on top of the partial-function mechanism — there is no single built-in idiom as convenient as Erlang's tagged tuple.

Erlang's behaviours (like gen_server) are a loosely-checked convention — a compiler warning at most if a callback is missing, and only relevant once the behaviour is actually used at runtime. Pony traits are fully enforced at compile time: class Person is Greetable without a greet method simply fails to compile. Pony also supports structural typing via interface (no explicit is declaration needed, just matching methods) alongside nominal typing via trait (explicit is required) — a distinction with no Erlang parallel at all, since Erlang has neither.

Erlang lists are singly-linked cons cells with cheap prepend and no efficient random access. Pony's Array[T] is a contiguous, indexable, growable sequence, closer to Go's slice or Rust's Vec — there is no [Head | Tail] destructuring pattern; indexing with numbers(0) is itself a partial operation (hence the trailing ?), since an out-of-bounds index is a genuine runtime error.

The base case and recursive case survive intact, expressed as an if/else inside one primitive function rather than as separate clauses — Pony, like Go and Clojure, dispatches on a single function body rather than choosing among clauses by argument shape.

OTP's supervisor behaviour — declaring which children to restart, how often, and under what strategy — is a first-class, battle-tested part of Erlang's standard library. Pony ships nothing playing this role: an actor that errors simply stops, and automatic recovery is something you would have to design and implement yourself. This is the same gap Go has relative to Erlang, and it is a real one — Pony's compile-time safety guarantees reduce how often you need recovery, but do not replace OTP's answer for what to do when recovery is still needed.

Erlang has no null concept whatsoever — undefined is just a regular atom, with zero special compiler treatment. Pony also has no null and no exceptions in the traditional sense — "a value or nothing" is expressed with a union type like (I64 | None), and the compiler forces you to match both cases before using the value, catching what would be a null-pointer-style bug in most other languages at compile time.

This is a close match: Erlang's X = 40 can never be rebound, full stop. Pony's let x: I64 = 40 gives the identical guarantee — reassignment is a compile error — but, like Rust and F#, Pony offers an explicit escape hatch: declaring the binding var instead of let permits real mutation, something no Erlang variable can ever opt into.