That Starts With E

So You Want to Run Code That Starts With E

I keep seeing people try to compile their first project and immediately hit a wall because they installed the wrong build of the compiler. Let me save you the headache. The issue isn't your code. It's that the ecosystem splits into two paths early on, and if you pick the wrong one, everything downstream gets messy. Before I get into the actual setup, here's what nobody tells you: Elixir runs on the BEAM virtual machine, the same one that powers Erlang. That means it inherits things like hot code reloading, massive concurrency, and fault-tolerance primitives out of the box. It also means your error messages will sometimes reference Erlang terminology and you'll feel lost for about ten minutes every time. That's normal. Just get comfortable reading them.

What Exactly Is That Starts With E

It's a functional programming language built on top of Erlang's runtime. Designed by José Valim and first released in 2012, it gives you metaprogramming capabilities through macros, a pipe operator that makes data transformation readable, and pattern matching that replaces most conditional logic you'd normally write. The syntax looks almost like Ruby. It isn't. Don't write Ruby code and pretend it'll work cleanly. The biggest misunderstanding I see is people treating it like a general-purpose language they can drop into any project. It excels at concurrent systems, real-time applications, and services that need to stay up for years without restarting. It's not the right call for CPU-bound numerical work or when you need tight memory control. If your project is mostly CRUD with some messaging queues, you're in the sweet spot. If you're building a game engine, look elsewhere.

Installing It Without Crying

The recommended installation method is through a version manager. I use asdf because it handles both the language runtime and the Erlang/OTP dependency in one place. Installing them separately through your package manager almost guarantees version mismatches later. I learned this the hard way in 2019 when a production deployment failed because the CI server had a different OTP version than my local machine and the compiler silently accepted incompatible beam bytecode. Took me six hours to trace. Here's what you actually run: First, make sure asdf is installed on your system. Then add the plugins:

asdf plugin add erlang asdf plugin add elixir Check what versions are available with asdf list-all erlang. Pick a version that matches or exceeds the minimum required for your Elixir version. The official docs publish a compatibility matrix. If you ignore it, your project will refuse to start and the error output will be intentionally vague. This is by design, apparently. Install both, then set them as your global default:

asdf global erlang 26.2.5 asdf global elixir 1.16.3-otp-26 Verify the installation by running elixir --version. You should see the Elixir version and the corresponding OTP release listed below it. If it errors out with something about erl not found, your shell profile hasn't loaded the asdf shims yet. Run eval "$(asdf shell-variables)" or add those lines to your .zshrc or .bashrc file. It's a one-time thing.

Creating and Running a Project

Generate a new project with mix new my_app --sup. The --sup flag adds a supervision tree from the start. Skip it if you want the bare minimum, but you'll add one eventually anyway. I always include it from day one because the alternative is rewriting the directory structure halfway through development. Navigate into the project and run mix test. Mix is the build tool. It handles compilation, dependencies, testing, and deployment. Everything flows through it. If you try to use a different tool, you're fighting the ecosystem. Don't do that. Open test/my_app_test.exs and you'll see a basic test using the ExUnit framework. Run mix test --trace to watch it execute line by line. This is useful for understanding how Elixir tests scope their expectations. Each assertion is isolated. Setup blocks run before each test, not once per file. I used to forget this and had flaky tests that passed locally and failed on CI for three weeks straight. The fix was simple: stop relying on module-level state in tests.

To run your application, use mix run --no-halt. Without --no-halt, the process exits immediately after executing your script. This trips up everyone at least once.

Dependency Management That Actually Works

Your mix.exs file declares dependencies. Add them to the deps function. A typical entry looks like: {:plug, "~> 1.14"} The tilde-greater operator allows patch-level updates but blocks breaking changes. That's the default behavior and it's correct. Remove the tilde only if you understand what you're doing. :plug is a HTTP handling library for building web applications. It's the standard choice. Phoenix, the web framework most people reach for, builds on top of it.

After editing mix.exs, run mix deps.get to fetch and compile dependencies. This downloads source code, compiles it against your current OTP version, and caches the results. Subsequent builds reuse the cache unless a dependency changes. Compilation of a fresh project typically takes around two to four minutes on a modern machine. Incremental builds are usually under fifteen seconds. One thing that catches people off guard: Elixir dependencies are compiled into your project at build time. Unlike JavaScript, you don't ship source files. You ship precompiled beam bytecode. This is faster and more secure but means you can't monkey-patch a dependency's behavior at runtime without recompiling.

Common Pitfalls That Wasted My Time

The pipe operator |> does not create a closure. When you pass a function reference through a pipe, you're passing the module, function name, and arity. If you try to use it with an anonymous function without explicitly capturing it with the & syntax, the compiler will reject it. I wrote a data transformation pipeline that looked correct and spent forty-five minutes debugging a compile error that boiled down to missing &1 syntax. Another issue: string encoding. Elixir strings are UTF-8. But when you interact with the operating system, databases, or external APIs, the encoding boundary shifts. I had a bug where Unicode characters from user input were being truncated at the PostgreSQL connection level because the database client defaulted to Latin-1. The fix was setting the encoding: "utf8" option in the connection string. This kind of problem surfaces randomly and looks like a data corruption issue until you check the actual byte values. Pattern matching is powerful but dangerous in function heads. If you define multiple arities or clauses, the compiler matches them in order. A catch-all clause placed too early silences errors that should surface. I had a callback handler that silently dropped malformed messages because I wrote def handle(info, _state) before the more specific clauses. Moving it to the bottom fixed the issue instantly.

Running Code That Starts With E in Production

The BEAM makes deployment simpler than most languages because the runtime handles process isolation. Your application crashes don't take down other processes. But this also means your deployment strategy should account for hot code swapping. If you're using Phoenix or a plain BEAM release, tools like DISTillery or releases from the Elixir standard library handle building distributable packages. A minimal release build takes about five minutes and produces an executable you can copy to any machine running the same OTP version. You don't need to install Elixir or the compiler on the target machine. This is one of the biggest advantages over languages that require a runtime installation on every server. The main bottleneck I've encountered is memory usage. BEAM processes are lightweight, but each one carries overhead. A thousand processes might use forty megabytes. A million could push you past a gigabyte depending on what they're doing. If you're building a service that needs to track millions of concurrent connections, profile your memory before deploying. :observer.start() gives you a graphical tool that shows process counts, memory usage, and message queue lengths in real time. It saved me from a production incident where we were leaking process references through a GenServer callback.

If your application is mostly synchronous and doesn't need the concurrency model, you might be better off with a different tool. Elixir's strengths show up under load, not in simple scripts. Writing a basic REST endpoint in it takes longer than in something lighter because of the framework boilerplate. That's acceptable trade-off for the reliability you get when traffic spikes.

Where to Go From Here

The official documentation at hexdocs.pm is thorough and maintained by the community. Start with the getting started guide and work through the programming model chapter before touching any web framework. Understanding GenServers, supervisors, and the OTP behavior protocols will save you weeks of confusion later. I skipped this step on my first project and spent three months unlearning habits that would have been obvious if I'd read the docs in order. Join the Elixir Forum or the Slack channel. The community is small enough that answers come quickly but large enough that you'll find real discussions about architecture decisions, not just hello-world help. Most of the seasoned developers I've talked to were happy to review a design doc or point out a subtlety I missed.