Elixir.CodeCompared.To/Pony

The very first line already tells you the two biggest things about Pony. The entry point is an actor, so the concurrency model is not a library you opt into — it is the shape of the program. And env being an explicit parameter rather than a global means there is no ambient IO module to reach for: capability-security runs all the way down, and a function that was never handed env is structurally incapable of printing.

Losing iex is the adjustment that stings longest. There is no place to paste three lines and see what they do, no h Enum.reduce, no recompile(), and no way to poke at a running system. What you get back is that the whole class of error above stops being a thing that happens in production at 3am — and a binary with no runtime to install, where an Elixir release still ships the entire BEAM.

This is the single most likely way an Elixir developer's first real Pony program produces a wrong answer instead of an error, because nothing warns you. Anywhere you were quietly relying on bignums — a factorial, a hash, an accumulating counter, money in the smallest unit — needs a deliberate choice of width now. Pony does offer checked (addc), saturating (add_partial, which is partial and can error) and explicitly-unsafe variants, but plain + is the wrapping one.

One rule Elixir does not have comes attached: because the if has a type, both branches must agree on one. Drop the else and the type becomes (String | None) — Pony supplies None for the missing branch rather than letting the expression be untyped. That is the whole reason None exists as a value, and it is why it shows up so often in the Types section.

Note what is missing from the Pony version: there is no @spec, because the signature is the spec and the compiler enforces it. Elixir's typespecs are optional annotations that only Dialyzer reads, and only sometimes; in Pony the same information is mandatory, checked, and used to generate the machine code.

The mental model transfers wholesale — this is the half of Pony you already know. Two differences worth noticing immediately: creating an actor is a typed operation, so worker is a Worker and not an opaque pid, and there is no Process.sleep at the end. The Pony program exits when every actor is quiescent, so it waits for the message you sent by construction rather than by you guessing at a delay.

Compare the amount of ceremony. The Elixir version needs a use GenServer, a start_link, an init that establishes the state, a handle_cast clause that pattern-matches a tag out of a tuple, and a {:noreply, new_state} return that threads the state forward by hand. Pony's equivalent is a field and a method: the dispatch on message name is the method name, and the state update is an assignment.

This is the first thing you will genuinely miss. Selective receive is how Elixir expresses "wait for the reply I care about and ignore the noise", and every use of it has to be rebuilt in Pony as explicit state: a queue field, a mode flag, a buffer you drain later. The upside is that a Pony mailbox can never contain a message nobody will ever match, which is the classic BEAM memory leak — an unbounded mailbox slowly filling with terms no receive clause accepts.

Coming from Elixir this feels illegal for about a day. Mutable state has always been the thing you were protecting against, and the discipline of threading it through return values is how you knew nobody else could touch it. Pony gets the same guarantee from the type system instead of from immutability, which means it can offer you plain assignment without giving up a single safety property.

The Elixir program prints one of two orderings depending on scheduling; the Pony program is deterministic, because the send to relay causally precedes the send to collector. This is a strictly stronger guarantee than the BEAM offers and it removes a family of races you may not have realized you were exposed to — though in practice most Elixir code never notices, because supervision and explicit replies paper over it.

The cost profile is close enough that a design that works on the BEAM usually works in Pony. The one thing that differs is death: an Elixir process ends when its function returns, and you can kill it from outside with Process.exit/2. A Pony actor has no exit and cannot be killed — it is garbage-collected when it becomes unreachable and its queue is empty, which means the runtime, not you, decides when it stops existing.

Hold on to this row; the rest of the section is the machinery that makes it legal. The Elixir version has copied 20,000 integers into a second heap and both processes now own an independent list. The Pony version passed one machine word, and both actors are looking at the same memory — which is safe only because val means "globally immutable, forever", so neither of them can write to it.

Notice that val can be sent to any number of actors any number of times, with no ceremony and no copy — because immutability makes aliasing harmless, which is the same reasoning that lets the BEAM share large binaries off-heap instead of copying them. val is where you should start and where most of your data should stay; the other capabilities exist for the cases where you genuinely need to mutate.

This is the row that pays for the whole system. In Elixir the only way to hand a mutable structure to someone else is to not have one — you build a new immutable version and send a copy. Pony lets you build it mutably, hand over ownership with zero copying, and keep mutating it on the other side, and it proves at compile time that you did not keep a back door open. consume is the syntax for "I am giving this away".

The everyday rhythm of Pony is ref for working data inside an actor, box for parameters you only read, and val or iso at the boundary where something crosses to another actor. That last clause is the part with no Elixir analogue at all: in Elixir every boundary crossing is a copy, so there is nothing to distinguish and no annotation to write.

Seeing the pid described as a capability reframes the whole system: Elixir gives you exactly one of the six, applies it to exactly one kind of thing (processes), and hardcodes it. Pony generalizes that idea to every reference, so "what am I allowed to do with this, and who else can do it at the same time" becomes a property the compiler tracks for ordinary data too — not just for processes.

This pattern — mutate locally, freeze, then share — is the Pony answer to almost every place Elixir would have used Enum.reduce into a new immutable term. You get the efficiency of in-place building without giving up the guarantee that what you eventually publish can never change under a reader, and the recover block is the exact point where the compiler signs off on the trade.

The remaining capability, trn (transition), is the rarest: a writable reference that hands out read-only box aliases, so you can build something up while others watch, then freeze it to val. Most programs never need it. If you learn only three, learn val, iso and ref — they cover the overwhelming majority of real code.

The distinction that matters is not let versus var — it is that Pony genuinely overwrote the same memory while Elixir built a new value and pointed a new name at it. In a single-threaded body the difference is invisible, which is exactly why it is safe; the reference capability system is what stops it from being visible anywhere it would matter.

Losing assignment-as-assertion is a bigger adjustment than it sounds. A great deal of Elixir's error handling is really = failing loudly on an unexpected shape and a supervisor restarting the process. Pony has neither half of that: the shape is checked at compile time instead, so the runtime assertion is unnecessary, but there is also no supervisor waiting to catch what you did not anticipate.

Two things to unlearn. There is no Enum module to reach for, so the loop is the idiom rather than a fallback you would be judged for — and a Pony for loop is an expression whose value is the last iteration's body, not a fold, so a running total must live in a var outside it. The Iter chain shown in the Collections section is the closest thing to Enum, but it is a library and not the default style.

The Elixir version pays for its mutable cell with a process, a copy on every read, and a serialization point. Pony's costs nothing extra, because the isolation the process was providing is already provided by the type system. Whole categories of "wrap it in an Agent" plumbing simply evaporate — though so does the ability to inspect that state from a remote shell, which the OTP Gap section returns to.

The interesting loss is not the typing, it is the polymorphism you had for free. The Elixir function happily took integers and then floats because nothing checked; the Pony one is committed to F64, and making it work for both means generics over a numeric trait. Where Elixir's answer to "what types does this take" is "whatever works", Pony makes you decide up front — and then never lets a caller be wrong about it.

A union is the closest thing Pony has to Elixir's "a variable holds whatever", and the difference is that the set of possibilities is written down and the compiler checks you handled all of them. Drop the String branch from that match and the program will not build — where the Elixir version would have fallen through to a CaseClauseError the first time production handed it something unexpected.

The commented-out line is the whole point: Pony will not let you call a String method on something that might be None, so the class of bug that produces FunctionClauseError at 3am simply cannot be written. The cost is that every optional value needs an explicit narrowing at the point of use, which is more typing than || and considerably more than an Elixir pipeline that quietly assumed the value was there.

Two things you gain over atoms. The match is exhaustive — add a fourth status and every match that forgot it stops compiling, where Elixir would have raised at runtime on the one code path nobody tested. And a primitive can carry methods, so the tag and the behavior that goes with it live together instead of being a bare atom plus a case in some helper module.

The trailing apostrophe in name' is a real identifier character in Pony, used by convention to name a constructor parameter after the field it initializes — there is no shadowing rule to work around, it is just a naming habit. The deeper difference is that birthday mutated the object rather than returning a new one, which is only possible because fun ref declares that it needs write access to the receiver.

The habit to break is {:ok, value}. Elixir's tagged tuple is the universal return convention precisely because there is no type system to express "one thing or another" — Pony has unions for that, and using a tuple where a union belongs gives up the exhaustiveness checking that makes the union worth having. Tuples in Pony are for genuinely fixed-shape groupings, like the coordinate above.

One rule catches everyone: a literal pattern in Pony matches with ==, so it only works for types that define equality, and a bare identifier is always a binding — never a comparison against an existing variable. Elixir needs ^ to say "compare, do not rebind"; Pony has no pin because a comparison against an existing value belongs in a guard, which the next rows cover.

The Elixir version has to use cond with guard functions because case cannot match on type, and every branch is still working with an untyped value — String.upcase(value) is only safe because you checked. Pony's arms genuinely change the type of the binding, so the compiler is the one guaranteeing that text.upper() is legal, and it will tell you if you add a member to the union and forget an arm.

Note the third arm calling passing, an ordinary function of your own — Elixir would reject that outright, since only guard-safe BIFs and macros defined with defguard are allowed in a when. That restriction exists because BEAM guards must be provably side-effect-free and fast; Pony evaluates the guard as normal code, so it has no such rule.

This is the most keystroke-visible loss on the page. Elixir's map patterns are partial by design — they assert only the keys you name and ignore the rest — and Pony cannot express that, because a Map is a hash table with runtime keys, not a structural type. Where the shape is genuinely known, the right Pony answer is a class with named fields, which is checked at compile time rather than asserted at runtime.

Reading that Pony match should feel almost like reading the Elixir one, which is a fair summary of the whole section: the shapes you match on are narrower, but the mechanism is the same one you already use dozens of times a day. What is new is that leaving out the Fahrenheit arm is a compile error rather than a lurking CaseClauseError.

The ? at the call site is the part with no Elixir equivalent and it is quietly excellent: reading a function body, every place that can jump out is marked. Elixir's ! naming convention (Map.fetch!) is trying to do this by discipline; Pony makes it syntax and has the compiler check it. Note also that the second call short-circuited the whole try — "never reached" is genuinely never reached.

Every Elixir habit built on {:error, reason} — matching on the reason, logging it, mapping it to an HTTP status — has to move somewhere else. The idiomatic Pony answer is the next row: return a union that includes your own error type, and keep error for cases where "it did not work" really is all the caller needs. Treat ? as control flow, not as error reporting.

This is the shape to reach for by default, and it is better than the tagged tuple in one specific way: the compiler knows the complete list of things parse can return, so a caller that forgets the failure branch does not compile. In Elixir nothing stops you writing {:ok, port} = parse(text) and discovering the other case in production.

The Pony version is shorter and needs no special construct, because ? is already a short-circuit. What it cannot do is Elixir's else clauses that match on which step failed and with what reason — there is only one featureless error, so distinguishing the failures means going back to the union return from the previous row.

This is the biggest cultural adjustment of the whole page. Elixir lets you be optimistic because OTP is underneath you; Pony expects the compiler to have eliminated most failures up front and leaves the rest entirely to you. In practice that means writing try ... else where you would have written nothing, and building recovery by hand — which the OTP Gap section takes up next.

Read the Pony side carefully: the worker had to volunteer that it was in trouble. There is no Process.monitor, no {:DOWN, ...}, no link, and no way for an outside actor to observe that a behavior aborted. Losing OTP is by far the largest thing an Elixir developer gives up moving to Pony, and it is a fair trade only because the type system removed many of the failures the supervisor was there to absorb.

The mechanical cost is small; the stylistic cost is not. GenServer.call lets you write straight-line code that reads top to bottom, and a Promise turns every request into a callback, so a sequence of three dependent calls becomes three nested closures. Pony offers no await, so this really is the shape — which is a strong argument for designing actors that push results forward rather than being asked for them.

You lose the ability to reach anything from anywhere, which is genuinely convenient and genuinely a source of hidden coupling — a named process is a global variable wearing a hat. Explicit wiring makes the dependency graph visible in the constructors, at the cost of threading references through layers that did not previously need to know about them.

The reason is the same one that makes the whole system work: a reference capability is a compile-time proof about one address space, and there is no way to extend that proof across a network. Erlang bought distribution by copying every message, which is exactly the cost Pony declined to pay. If a clustered BEAM is central to your design, this is the row that should give you pause.

Losing hot upgrade rarely matters — most Elixir shops deploy by restarting anyway — but losing introspection often does. There is no remote shell to attach, no :sys.get_state on a misbehaving actor, and no live mailbox lengths. Observability in Pony is whatever logging and metrics you built in advance, which is a real change in how you debug production.

Two habits to retire. Indexing is cheap now, so the Elixir instinct to avoid Enum.at in a loop no longer applies — but it can fail, so it drags a try along with it. And push mutated the array in place rather than producing a new one, which means passing an array to a function that takes a ref is handing over write access, not a snapshot.

The unfamiliar part is that this Map is mutable and iteration order is unspecified — Elixir maps are immutable and small ones iterate in key order, which a surprising amount of code accidentally depends on. If you want the Elixir semantics exactly, the persistent map in the next row is the closer match.

Reach for these whenever a collection has to cross an actor boundary or be shared widely, since a persistent collection is naturally val and needs no recover. The trade is the one Elixir already made and you already know: structural sharing costs an allocation and a pointer chase per update, where the mutable Map writes in place.

This is the closest Pony gets to the pipeline you write every day, and it is close enough to be comfortable — but note it is a library type wrapping an iterator, not a protocol every collection implements. There is no Enumerable, so a type you define does not automatically work with Iter unless you give it a values() method returning an Iterator.

Pony spells union and intersection as the operators or and and, which reads well once you expect it — these are ordinary method names (op_or, op_and) that the operator syntax desugars to, the same mechanism that makes + work on your own classes. Elixir has no operator overloading at all, so MapSet.union is the only spelling available there.

Comprehensions are one of the places Elixir is simply more expressive, and there is no Pony feature that closes the gap — the nested loop with an explicit accumulator is the idiomatic answer, not a workaround. What you do get in exchange is that Range is an ordinary iterator you can hand to Iter, so lazy pipelines and loops compose from the same pieces.

It is more typing, and it is also the one place Pony feels genuinely dated next to Elixir. The compensation is that .string() comes from the Stringable interface, so any type you define gets to say how it renders and the compiler will not let you concatenate something that has not — where #{} will happily interpolate an inspect-ish fallback for a struct nobody wrote a String.Chars implementation for.

Both languages are solving the same problem — naive concatenation in a loop is quadratic in both — but note where the safety comes from. Elixir's iodata is safe because everything is immutable and the flattening is a pure function; Pony's is safe because the recover block proves nothing mutable escaped, which is why the result can be handed to another actor without a copy.

Neither language gives you graphemes for free — Elixir's String.length counts codepoints too, and String.graphemes is the one that handles combining characters. Pony has no grapheme support in the standard library at all, so text that needs real Unicode segmentation is a place where Elixir's standard library is meaningfully ahead.

Two Pony details show up here. strip and replace mutate in place rather than returning a new string, so they need a ref — which is why clone() appears, since a literal is val. And .> is the "call this and return the receiver anyway" operator, the closest thing Pony has to chaining a mutating call, which the next section revisits when the pipe operator comes up.

The Elixir version is undeniably lighter to write. What the Pony version buys is exhaustiveness: add a Triangle to the union and the compiler points at this match, where Elixir would raise FunctionClauseError the first time one reached this function in production. Also note fun apply — naming a method apply is what makes Area(...) callable like a function.

Compare the two cells honestly: this is the row where Pony is at its least pleasant to read, and no idiom fixes it. Chaining only works when each step is a method on the value, so a standard library organized as free functions — which most of Pony's is not, fortunately — would be painful. Expect intermediate let bindings where you would have written a pipeline. One trap in passing: Pony's split takes a set of delimiter characters, not a delimiter string, so split(", ") would break on the comma and the space and leave an empty field between them — split_by is the one that takes the whole string, and it is what String.split/2 does in Elixir.

Calling a lambda needs no dot — double(21), not Elixir's double.(21) — because a Pony lambda is an object with an apply method and calling it is ordinary method-call syntax. That also means the function type {(I64): I64} val is just an interface — capability and all, which is why the parameter has to say val — so anything you write with a matching apply can be passed where a lambda is expected.

The third call is the one Elixir cannot express: skipping a middle argument and naming a later one. Elixir's workaround is the trailing keyword list, which pushes the checking to runtime — a typo in an option key is silently ignored — where Pony's named arguments are checked by the compiler like any other parameter.

That annotation is what lets the compiler prove the sharing rules hold — a box reference will not let you call record at all, so a function that promised only to read genuinely cannot write. The Elixir version achieves the same guarantee by making mutation impossible, at the cost of rebuilding and rebinding the struct on every single update.

Look at what the Elixir version needed to get default implementations: a __using__ macro that injects code into the caller. That is the standard workaround and it is why so much Elixir library code is macro-heavy — a @behaviour alone cannot carry an implementation. Pony gets the same result with a plain method body and no metaprogramming at all.

Neither Rope nor Cable mentions Measurable, which is the point — structural typing lets you retrofit an interface onto types you did not write, the same freedom defimpl gives you for a foreign struct. The difference is that Pony resolves it statically, so there is no dispatch table and no Protocol.UndefinedError waiting at runtime.

This is a real ergonomic loss and the reason is deliberate: Pony has no equivalent of Elixir's protocol consolidation step, and allowing out-of-module trait implementations would break the compiler's ability to reason about a type from its definition alone. Structural interfaces absorb most of the pain — they need no declaration at all — but only when the foreign type already happens to have the right method. The Elixir cell is display-only: a user-defined defprotocol with two defimpls does not finish inside the in-browser AtomVM's 45-second compile budget.

Generics are the feature with no Elixir counterpart whatsoever, and the useful part is the constraint rather than the parameter. A: Stringable val is a contract the compiler enforces at every instantiation, so Box cannot be built around something it could not render — which is precisely the class of mistake the Elixir version discovers only when describe is finally called.

The trade is speed for reach. Pony's dispatch costs nothing at runtime and cannot fail, but the set of implementations is fixed when the binary is built; Elixir's can be extended by any library that loads later, which is what makes Jason.Encoder and Inspect work for types their authors never saw. Neither answer is better — they are different points on the same trade-off.

Pony goes one step further than the BEAM: because reference capabilities tell the collector exactly which actors can reach an object, there is no tracing pause across actors and no separate binary heap with its own reference counting to reason about. In practice both give you the same headline property — no global stop-the-world pause — and it is one of the few places where moving to Pony asks you to change nothing at all.

On a multicore machine this usually looks fine, because the other actors are on other threads — the danger appears when you have more busy actors than cores, or one behavior that blocks. Two BEAM reflexes stop working: a runaway loop cannot be killed from outside (there is no Process.exit), and long work must be chunked into several behaviors by hand so the actor yields between them.

This is a genuine advantage over the BEAM and it needs no library. Muting is transparent — the producer's code is unchanged and it simply gets scheduled less — so the "unbounded mailbox eats the node" failure mode is handled by the runtime rather than by you adopting GenStage. It also means a Pony actor cannot easily be used as a deliberate buffer, since the runtime will slow the producer down whether you wanted that or not.

The consequence for design is that "stop this worker" is not something you do — you drop your reference and let it drain. A stuck actor holding a reference to itself, or reachable from a long-lived registry-like actor you built, will simply never be collected, and unlike the BEAM there is no supervisor timeout and no :observer process list to notice it with.

Every macro you have written turns into either a function, a bit of repetition, or a code generator you run before ponyc. Notice specifically what the function cannot do: recover the source text of its own arguments. Anything that depends on seeing the expression rather than its value — assertion messages, ExUnit's failure output, query DSLs — has no Pony equivalent at all.

For this particular job the trait is arguably the better tool — it is readable, the compiler checks it, and defoverridable becomes just overriding a method. What traits cannot do is everything __using__ does beyond adding methods: registering module attributes, generating functions from a schema, or building code from data available only at compile time.

The ~ is partial application, which turns Upcase.apply into a value you can store and pass — that is as dynamic as Pony gets, and the set of choices is fixed at compile time. Anything built on genuine runtime reflection, from plugin loading to Phoenix.Router's dispatch, has to be restructured as an explicit table of function values.

The file-is-not-the-unit rule catches people out: there is no import of a single type and no per-file privacy, so everything in a directory sees everything else in it, and use brings in a whole package at once. Privacy is by naming convention instead — a leading underscore, as on the actor fields throughout this page, makes a name package-private.

Be honest with yourself about this row before committing to Pony for real work. Hex has JSON, HTTP clients, database drivers, Ecto and Phoenix; Pony has a standard library that covers the fundamentals well and a community-maintained handful of packages beyond it. For systems programming that is often enough, and for a web application it usually is not.

Note that Main itself becomes the test list, which is how a Pony test binary works — you compile a test directory into its own executable rather than running a task. The assertions are ordinary generic functions rather than macros, so a failure reports the two values but cannot show you the expression that produced them, which is the concrete cost of having no macro system. The Elixir cell is display-only: ExUnit is not part of the in-browser AtomVM build, and ExUnit.start/1 dies on a missing :erlang.apply/3.