BEAM PathErlang + Elixir
Start learning
Erlang basics · Lesson 09 (open contents)
01 · Open erl02 · Meet common terms03 · Tell two kinds of text apart04 · Bind a variable once05 · Split and filter a list06 · Parse a number safely07 · Choose one path with case08 · Let a function keep going09 · Put code in a module10 · Compare terms and Boolean results11 · Read and update nested maps12 · Build and inspect UTF-8 binaries13 · Let clauses choose the function path14 · Solve a list twice15 · Choose with patterns, guards, and errors16 · Describe a module and one record17 · Put one tested module in Rebar318 · Return success or failure as data19 · Read and write one file safely20 · Build a data pipeline with functions21 · Keep records behind a module boundary22 · Define a module contract23 · Describe the data contract24 · Test small rules and whole flows25 · Shape builds and make a command26 · Write the project promise27 · Parse one real line28 · Keep the public API small29 · Make the promise executable30 · Package the edge and leave clues31 · Prove the project is done
Home/From Scratch/Erlang/Lesson 09
ERLANG · SCRATCH · LESSON 0940 minutes

Put code in a module

Save functions in an `.erl` file, compile them, and look ahead to BEAM.

01 · Start with the whole example

Save as village.erl

After saving, open erl in the same folder and run c(village)..

Erlang
%% Keep the file name and module name the same
-module(village).

%% Allow code outside the module to call greet/1
-export([greet/1]).

%% Name is a binary
greet(Name) ->
  <<"hello, ", Name/binary>>.
Check the result first
  • When compilation succeeds, c(village). returns {ok,village}.
  • village:greet(<<"Maya">>). returns <<"hello, Maya">>.
02 · Take the code apart

Read from the first line down

  1. -module(village). declares the module name. The file should be village.erl.
  2. /1 in -export([greet/1]). says that greet takes one argument.
  3. Name/binary appends the incoming binary to the fixed text.
  4. After compiling, call it with module:function(argument): village:greet(<<"Maya">>).
03 · Meet the new symbols

Symbols are not secret signs

-module(village).

Declare the module name as village. The file should be called village.erl.

-export([greet/1]).

Make the one-argument greet function public.

c(village).

Compile and load village.erl in the Erlang shell.

04 · Ideas inside the code

Match each name to its meaning

01

module

A group of functions in one .erl file. The module name usually matches the file name.

02

export

A list of functions that code outside the module may call. Each item uses name/arity.

03

process

A small, independent unit of work on the BEAM. Processes work together by sending messages.

05 · Make the idea clear

Why these forms are useful

The shell is like scratch paper. Named functions that need to be saved and reused usually belong in a module file. The file name and module name should match.

-export([greet/1]). allows code outside the module to call greet/1. The /1 matters because functions with the same name but different arities are different functions.

Once the module runs, you are ready for BEAM's strengths: small processes, messages, supervision, and recovery from failures. Those belong to the next learning path.

DESIGN DECISION

Why this shape?

Why organize functions in modules before reaching for a class?

Choice

A module names related functions and creates a public boundary. Data remains an explicit argument instead of hiding behind this.

Cost and boundary

Add a process only when state needs an owner, a lifecycle, or failure isolation. A GenServer around a pure function merely adds a queue.

A FAMILIAR POINT OF VIEW

Coming from Java, Python, or JavaScript

Java

Familiar starting point
A class combines data, methods, and object identity.
What BEAM changes
A BEAM module is not an object, and functions have no implicit receiver.
False friend
Calling a module does not start a process.

Python

Familiar starting point
Modules and classes can both organize code.
What BEAM changes
Module/function/arity forms the stable entry point; state is a separate design decision.
False friend
An OTP Application is not an operating-system process.

JavaScript

Familiar starting point
ES modules export functions or classes.
What BEAM changes
BEAM calls compiled modules by module name and arity.
False friend
Mix and rebar3 manage projects; neither is BEAM or OTP.
06 · Change it yourself

Close the answer and try

Add a public function farewell/1 that returns <<"bye, ", Name/binary>>.

Practice starting point
-module(village).

%% Export one more function in this list
-export([greet/1, ____]).

greet(Name) ->
  <<"hello, ", Name/binary>>.

%% Complete the new function
____(Name) ->
  <<"bye, ", Name/binary>>.

Target result: After compiling again, village:farewell(<<"Maya">>). should return <<"bye, Maya">>.

Stuck? Read one hint

Put farewell/1 in the export list. Put only farewell in the function definition.

After you run it, see one answer
One answer
-module(village).

%% Both functions take one argument
-export([greet/1, farewell/1]).

greet(Name) ->
  <<"hello, ", Name/binary>>.

%% The final function definition ends with a dot
farewell(Name) ->
  <<"bye, ", Name/binary>>.
Think about it: Why does the export list say `greet/1` instead of only `greet`?

Erlang identifies a function by both its name and its number of arguments. greet/1 and greet/2 are different functions.

Take with you

Remember these three lines

  1. 1

    Keep the module name and .erl file name the same.

  2. 2

    An export list identifies functions with name/arity.

  3. 3

    After learning the syntax, continue to BEAM processes and messages.

Lesson completeRun the code once, then mark this lesson as done.