Articles

When you practice algorithm problems in Python, the standard library offers an impressive array of tools. You reach for collections.defaultdict when counting frequencies, heapq for priority queues, itertools for permutations, and expressive slicing syntax to reverse or partition arrays in a single stroke. These high-level abstractions make production code concise and expressive. But during algorithmic training, they often act as a veil, obscuring the pointer arithmetic, memory layouts, balancing mechanics, and time complexities that the exercise was designed to teach.

On this site, you can write solutions in Lua alongside Elixir, Erlang, and TypeScript. Running Lua directly on the BEAM - using Robert Virding’s Luerl engine - provides a sharp contrast to standard scripting runtimes. Lua strips away standard library magic to force first-principles algorithmic thinking. At the same time, Luerl embeds an isolated scripting environment straight into BEAM processes with native sandboxing, preemption, and supervision.

The abstraction trade-off: crutches versus mechanics

Consider what happens when you solve a sliding-window or frequency-counting problem in Python:

from collections import Counter

def top_k_frequent(nums, k):
    counts = Counter(nums)
    return [item for item, count in counts.most_common(k)]

This code is concise, idiomatic, and effective for production. But what did you actually build? You did not allocate a hash table, manage collision resolution, maintain a min-heap of size k, or reason about the amortized cost of inserting elements. The language solved the mechanics for you.

When you switch to Lua, the safety nets vanish:

local function top_k_frequent(nums, k)
  local counts = {}
  for i = 1, #nums do
    local val = nums[i]
    counts[val] = (counts[val] or 0) + 1
  end

  -- No built-in heap: you extract keys and sort or build your own selection
  local unique = {}
  for val, count in pairs(counts) do
    unique[#unique + 1] = {val = val, count = count}
  end

  table.sort(unique, function(a, b) return a.count > b.count end)

  local result = {}
  for i = 1, k do
    result[i] = unique[i].val
  end
  return result
end

In Lua, there is no Counter, no defaultdict, no heapq, and no negative array slicing. If you need a stack, a queue, a binary search tree, or a graph adjacency list, you construct it out of the primitives provided. This constraint turns the language into a diagnostic tool for your algorithmic mental model: you cannot lean on library shortcuts when the library intentionally does not provide them.

The minimalist data model

Lua achieves its expressive power with an exceptionally small core. The entire language revolves around eight basic types: nil, boolean, number, string, function, userdata, thread, and table.

For data structures, there is exactly one constructor: the associative table.

A Lua table is both a hash map and a dynamically sized array. When indexed with sequential integers starting from 1, it functions as an array:

local list = {10, 20, 30}
table.insert(list, 40) -- Appends to index 4
print(#list)           -- 4

When indexed with strings or arbitrary objects, it functions as a dictionary or record:

local node = {
  value = 42,
  left = nil,
  right = nil
}

By combining tables with Lua’s setmetatable mechanism, you can implement custom object-oriented prototypes, custom lookup logic, or specialized structures like ring buffers and disjoint-set unions. Because you have only one building block, you are forced to understand how higher-level abstract data types map onto primitive key-value associations and continuous memory chunks.

Robert Virding’s Luerl: an interpreter in pure Erlang

Embedding a scripting language into a host environment often requires writing native C extensions (FFI) or spawning separate OS processes. Both approaches introduce severe operational risks:

C extensions (like the standard PUC-Rio Lua C library or LuaJIT) run outside the BEAM memory model. A segmentation fault or buffer overflow in the C library crashes the entire Erlang VM node, taking down all running actors.
External OS processes (like running python script.py via ports or shell commands) introduce heavy process-spawning overhead, require pipe-based serialization, and are prone to orphaned zombie processes when timeouts trigger.

Enter Luerl, designed and implemented by Robert Virding (one of the co-creators of Erlang).

Luerl is a clean-room implementation of Lua 5.3 written entirely in pure Erlang. It does not bind to liblua.so or invoke C code. Instead, the Lua compiler, runtime state, call stack, and table memory are modeled as pure immutable Erlang data structures (tuples, maps, and records).

In Elixir, evaluating Lua code inside Luerl looks like this:

# Initialize a fresh Lua state
state = :luerl.init()

# Execute a script inside that state
script = """
local function fib(n)
  if n <= 1 then return n end
  return fib(n - 1) + fib(n - 2)
end
return fib(10)
"""

{result, updated_state} = :luerl.eval(script, state)
# result => [55]

Because the entire Lua state is just an Erlang term, you can serialize it, inspect it, pass it in messages between BEAM processes, or discard it to instantly reclaim all allocated memory without running a foreign garbage collector.

Concurrency, preemption, and reduction accounting

Running user-submitted or untrusted code in multi-tenant systems usually requires elaborate sandboxing machinery. In standard environments (like CPython or Node.js), a user script containing an infinite loop while True: pass will monopolize the OS thread. Because of the Global Interpreter Lock (GIL) or single-threaded event loops, runaway scripts can starve other tasks or freeze the runtime unless isolated behind external process managers.

On the BEAM, Luerl scripts inherit the core guarantees of Erlang process isolation and scheduling:

Reduction-based Preemption: The BEAM schedules work using reductions (a counter roughly proportional to function calls and loop iterations). Because Luerl is executed as standard Erlang function calls, the BEAM’s preemptive scheduler automatically counts reductions while running Lua code. Even if a user submits a script with an infinite loop, the BEAM preempts the process every 2,000 reductions, allowing other processes on the node to make progress without latency spikes.
Deterministic Timeouts and Supervision: To execute untrusted Lua safely, the runner wraps evaluation inside a supervised Task:

task = Task.async(fn ->
  :luerl.eval(user_script, :luerl.init())
end)

case Task.yield(task, 5_000) || Task.shutdown(task, :brutal_kill) do
  {:ok, {result, _state}} ->
    {:ok, result}

  nil ->
    {:error, :timeout}
end

When a timeout fires, Task.shutdown(task, :brutal_kill) terminates the BEAM process instantly. Because Luerl maintains no OS threads, shared heap memory, or open file descriptors outside the process dictionary, killing the BEAM process guarantees 100% cleanup with zero resource leakage.

Realistic BEAM use cases for embedded Lua

Why would an Elixir system embed Lua rather than writing everything in Elixir?

Dynamic Rule Engines and Routing: Allow non-engineer operators or external clients to define custom filtering rules, routing logic, or webhook payload transformations (for example, mapping Stripe or GitHub webhooks into internal schemas) in a sandboxed language without recompiling or redeploying the Elixir application.
Game Server Logic: MMO backends and multiplayer game servers built on Elixir can use Lua for quest scripting, item drops, and combat formulas. Game designers can tweak Lua scripts in real time while Elixir handles network connections, state distribution, and UDP packet transport.
Plugin Systems: Enable third-party developers to write plugins that run safely inside your multi-tenant SaaS application without risk of reading sensitive environment variables or executing unauthorized system commands.

By restricting the standard library in the initialized Luerl state, the host application controls exactly which capabilities (such as math or string utilities) the guest script can access.

Connecting to your practice

Understanding the relationship between language runtime abstractions and underlying execution mechanics makes you a more resilient engineer across all platforms: