C.CodeCompared.To/Erlang

C requires an explicit #include, a typed int main(void) entry point, and an explicit return 0 on success. Erlang has no entry-point requirement at expression level at all — io:format/2 with the ~n directive prints with a newline, and this expression runs directly with no wrapping function.

C separates statements with semicolons; Erlang shell expressions are separated by commas, with a single terminating period marking the end of the whole sequence — both simply execute top to bottom in the order written.

C checks add's parameter and return types at compile time — passing a pointer where an int is expected is a compile error. Erlang has no compile-time type checking at all — Add("two", 3) would compile fine (there is no separate compile step at expression level to catch it) and only fail once that exact line actually executes, raising a badarith error at runtime instead of being rejected up front.

Erlang's -spec type annotations plus the separate Dialyzer tool can catch a real class of type mismatches, but only for code that opts in and only when Dialyzer is actually run — a fundamentally different guarantee from C's type checker, which runs unconditionally, for every function, as a mandatory part of compilation.

There is no malloc/free pair to manage in Erlang, and no possibility of a memory leak from a forgotten free, a double-free, or a use-after-free dangling pointer. Each Erlang process has its OWN independent heap and its own garbage collector — a genuinely different memory model from a single shared C heap, meaning one process's collection pause never stops any other process.

C has exactly one heap per operating-system process, shared by every part of the program that runs inside it. Erlang gives every lightweight process its own independent heap, garbage collected independently — a structural isolation boundary C's memory model has no equivalent for at all.

A C variable can be reassigned as many times as the program likes — that is the entire point of a "variable." An Erlang variable, once bound, can never be rebound to a different value in the same scope; attempting to do so is a pattern-match failure ({badmatch, NewValue}), enforced structurally by the language, not just discouraged by convention.

This is a genuinely new capability, not just different syntax for something C already has. C's switch only matches literal integers/characters, with no destructuring at all — every "which shape is this value" decision must be an explicit chain of if/else over already-extracted fields. Erlang's case matches against a VALUE'S SHAPE directly — tuples, lists, and specific literals can all be destructured and matched in the same expression, with an optional when guard attached to any clause.

Erlang's {X, Y} = Pair destructures a tuple into named variables in one matching expression. C has no tuple type at all; the closest analogue, a struct, still requires accessing each field individually (pair.x, then pair.y) rather than pulling both out in a single destructuring step.

A C struct is a fixed, named, typed layout declared once at compile time. An Erlang tagged tuple like {point, 3, 4} is just an ordinary tuple whose first element happens to be a distinguishing atom by convention — there is no compile-time declaration checking that every "point" tuple actually has this shape; it is enforced only by the pattern match at the point of use.

C's closest tool for "one of several shapes" is a hand-assembled tagged union: an explicit tag field, a union of the possible payloads, and manual discipline to always check the tag before reading the right union member (reading the wrong one is undefined behavior, with no compiler help). Erlang tagged tuples give the same idea directly, with the tag and payload already bundled together and pattern matching doing the discrimination safely.

C strings are a contiguous buffer of bytes terminated by a \0 sentinel — strlen must scan byte by byte until it finds that terminator. Erlang's double-quoted "hello" is secretly a LIST of integer character codes, [104, 101, 108, 108, 111] — length/1 is the same function used for any list, since a string genuinely is one.

C requires a pre-sized destination buffer for any string copy, and writing more bytes than the buffer holds is undefined behavior — the classic buffer-overflow bug. Erlang's list-of-codes representation grows to whatever length the actual data requires; there is no fixed-size buffer to overflow at all.

This is a genuinely new ABSENCE for a C developer to internalize, not a different syntax for something Erlang already has. Erlang values are manipulated purely by binding, matching, and passing — never by "where they live." C's &value (take the address) and *pointer (follow the address) expose the machine's actual memory layout directly, the foundation for C's performance and nearly every one of its classic bug categories, none of which Erlang can have at all.

Integer division by zero in C is undefined behavior — the C standard makes no guarantee about the outcome at all, and platforms genuinely differ (commonly a SIGFPE crash, but never guaranteed). Erlang's badarith is a well-defined, catchable, documented runtime error: dividing by zero produces exactly this exception, every time, on every platform, and try ... catch can handle it predictably.

This is the deepest philosophical gap between the two languages. A segfault, stack overflow, or sufficiently severe undefined behavior in C can bring down the ENTIRE process, taking every unrelated task running inside it down at the same time — C has no equivalent isolation boundary at all. An Erlang process crashing is a routine, local event: every other process keeps running, and a supervisor typically restarts the failed one within milliseconds.

C has no concurrency primitives in the language itself — POSIX threads are an OS-level library bolted on, and every thread shares the same address space by default, requiring explicit mutexes/locks to coordinate safely (and inviting classic data-race bugs when a lock is forgotten). Erlang processes are lightweight, BEAM-managed, and share NOTHING by default — the only way to communicate is explicit message passing (! and receive), structurally ruling out an entire category of shared-memory data races.

An OS thread in C typically costs megabytes of reserved stack and real kernel scheduling overhead — spawning tens of thousands of them is a genuine resource commitment, often impractical. Erlang processes are managed entirely by the BEAM runtime, starting at only a few hundred bytes each; spawning ten thousand of them, as shown, is unremarkable, everyday Erlang.

This is a genuine, direct parallel: C's #define NAME Value and Erlang's -define(NAME, Value). are both preprocessor-level textual substitution — the macro name is replaced with its expansion before the code is even compiled, with no awareness of scope, types, or syntax structure. Neither is the more powerful syntactic/hygienic macro system Clojure, Rust, or Elixir offer.

A C array is a fixed-size, contiguous memory block with O(1) indexed access — its size is baked in at declaration and cannot grow. Erlang's [1, 2, 3, 4, 5] is a singly-linked list — indexing the Nth element is O(n), but prepending an element or matching the head off the front is O(1), the opposite performance profile from a C array.

C has no built-in higher-order collection functions at all — transforming every element of an array means writing an explicit indexed loop by hand, allocating the destination array separately, and managing both bounds yourself. Erlang's lists:map/2 does the same job in one call, with no manual loop, no separate destination allocation, and no index bookkeeping.

This is a real, formal difference, not just a style preference. Whether GCC turns sumTo's recursive call into a loop is an OPTIMIZATION the C standard never requires — it depends on the compiler, the optimization level, and even unrelated code changes; a sufficiently large call could genuinely overflow the stack. The Erlang/BEAM specification formally GUARANTEES proper tail-call optimization for a call in tail position, in every implementation, at every optimization level — a language guarantee, not a compiler courtesy.

An Erlang atom like ok is a self-evaluating, interned constant that springs into existence at the point of use — no declaration required anywhere, and comparable across the whole program regardless of context. C's closest analogue, an enum constant, must be declared upfront as part of one specific enum type, and prints as a bare integer by default (as shown — OK prints 0, not a name), unlike an atom, which always prints its own name.

C's NULL is a genuine, structural hazard: any pointer might be NULL, and dereferencing one that is triggers a crash — one of the most common C bugs of all. Erlang has no null concept whatsoever; the convention of using the atom undefined to mean "no value" is just that, a convention, with no special compiler enforcement the way NULL at least gets a dedicated comparison and crash-on-dereference behavior in C.