Your First Erlang Program
Every piece of Erlang code lives inside a module: a single .erl file whose name matches the -module() declaration at its top, such as -module(greeter). for a file named greeter.erl. Functions inside a module are private by default and must be listed in an -export() attribute, written as a list of Name/Arity pairs, before code outside the module can call them — a deliberate design that makes a module's public API explicit at a glance.
Cricket analogy: A module's -export() list is like a team sheet handed to the umpire before the match: only the eleven listed players are allowed to take the field, and everyone else stays in the dressing room.
Writing and Compiling a Module
A minimal module needs at least the -module() attribute and one function; compiling it from the Erlang shell with c(greeter). invokes erlc under the hood and loads the resulting greeter.beam bytecode file directly into the running shell session, ready to call as greeter:hello(). Compiling from the command line instead with 'erlc greeter.erl' produces the same .beam file without starting an interactive session, which is how modules get built as part of a larger project or release.
Cricket analogy: Running c(greeter). in the shell to compile and immediately test a function is like a net session where a bowler tries a new delivery and gets instant feedback before it's used in a real match.
Running Code in the Interactive Shell
The Erlang shell, started with 'erl', numbers each input line like 1>, 2>, 3> and echoes the result of every expression, making it an ideal place to experiment with modules as you build them; it also keeps command history accessible with the up arrow and supports tab completion for module and function names. Calling a function fully qualified as Module:Function(Args) is required outside the module itself, since Erlang has no notion of importing a function into the global namespace by default.
Cricket analogy: The Erlang shell numbering each command like 1>, 2>, 3> is like a scorer logging every ball of an over individually, so you can always see exactly what happened and in what sequence.
A Complete Worked Example
Putting the pieces together: a module declares its name, exports the functions callers need, defines those functions (often using pattern matching across multiple clauses as covered earlier), and gets compiled and exercised from the shell. This compile-test-tweak loop, repeated in seconds thanks to the shell's fast reload, is the core workflow every Erlang developer uses long before reaching for a full build tool like rebar3 on larger projects.
Cricket analogy: The compile-test-tweak loop in the shell is like a net practice cycle: bowl a delivery, get immediate feedback from the coach, adjust the grip, and bowl again within seconds.
%% File: greeter.erl
-module(greeter).
-export([hello/1, hello/0]).
hello() ->
hello("World").
hello(Name) when is_list(Name) ->
io:format("Hello, ~s!~n", [Name]);
hello(_Other) ->
io:format("Hello, stranger!~n").
%% In the Erlang shell, from the same directory as greeter.erl:
%% 1> c(greeter).
%% {ok,greeter}
%% 2> greeter:hello().
%% Hello, World!
%% ok
%% 3> greeter:hello("Ada").
%% Hello, Ada!
%% ok
%% 4> greeter:hello(42).
%% Hello, stranger!
%% okErlang identifies functions by both name and arity, so hello/0 and hello/1 above are considered two completely separate functions that happen to share a name. This Name/Arity pairing is why -export() lists always look like [hello/1, hello/0] rather than just listing function names.
The file name must exactly match the -module() declaration, including case: a file named Greeter.erl containing -module(greeter). will fail to compile predictably on case-sensitive filesystems (Linux) and can cause confusing 'module not found' errors even on case-insensitive ones (macOS default, Windows).
- Every Erlang module lives in a .erl file whose name matches its -module() attribute exactly.
- Functions are private by default; only those listed in -export() as Name/Arity pairs are callable from outside.
- c(Module). compiles and loads a module directly into a running shell session for immediate testing.
- erlc Module.erl compiles from the command line without starting an interactive shell.
- Calling a function from outside its own module requires the fully qualified Module:Function(Args) form.
- Erlang distinguishes functions by name and arity together, so hello/0 and hello/1 are separate functions.
- The fast compile-test-tweak loop in the shell is the core beginner workflow before adopting build tools like rebar3.
Practice what you learned
1. What must match exactly for a module to compile correctly?
2. What determines whether a function can be called from outside its defining module?
3. What does c(greeter). do when run inside the Erlang shell?
4. How does Erlang treat hello/0 and hello/1 defined in the same module?
5. How must you call a function defined in a different module?
Was this page helpful?
You May Also Like
What Is Erlang?
An introduction to Erlang's origins, design philosophy, and the concurrent, fault-tolerant systems it was built to run.
Installing Erlang
How to install Erlang/OTP on macOS, Linux, and Windows, verify the installation, and manage multiple versions.
Pattern Matching in Erlang
How Erlang's = operator, function clauses, and guards use pattern matching to bind variables and control program flow.
Atoms and Terms
Understanding Erlang's atom data type and how atoms, numbers, tuples, and lists combine to form Erlang terms.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics