Is BEAM faster than the runtime I already know?

It is a reasonable question, but it frames the problem the wrong way.

BEAM was not designed to win every benchmark. Its roots are in Erlang, a language created for telecom systems where downtime was unacceptable. That history shaped a runtime built around a different problem: keeping many concurrent, stateful, independent activities running when parts of the system fail.

That is the key to understanding Erlang, Elixir, and OTP. The ecosystem is built around a specific view of software: systems fail, networks fail, dependencies fail, processes get into bad states, and production does not care about your clean abstraction boundaries.

The answer is not to prevent every failure. It is to make failure contained, observable, and recoverable.

So the better evaluation question is:

Does my system need to manage many long-lived activities that own state, communicate, fail, and recover independently?

If the answer is yes, BEAM deserves serious consideration.

The constraints explain the runtime

A useful way to understand the runtime is to look at the constraints it optimizes for.

BEAM assumes your system may need many concurrent activities, long-lived stateful processes, isolation between components, failure containment, recovery without restarting the whole system, soft real-time responsiveness, runtime observability, distributed communication, and operational continuity.

Those constraints explain the design choices: processes must be cheap, memory should be isolated, failures need to be observable, recovery needs to be explicit, and scheduling must prevent one process from monopolizing the system.

The design is coherent because these choices reinforce each other. Lightweight processes, message passing, supervision, per-process memory, and observability are not isolated features. They are different answers to the same core constraint: preserving service continuity under concurrency and failure.

The core design: process ownership

The most important architectural shift is process ownership.

In many ecosystems, engineers design around classes, modules, services, handlers, queues, repositories, and thread pools. In Erlang and Elixir systems, you also design around processes.

A process is a lightweight runtime-managed unit of execution. It is not an operating system process. It has its own memory, its own mailbox, and its own lifecycle. Processes communicate by sending messages.

This changes the way you model a system.

Instead of asking only:

Which module should contain this logic?

You ask:

Who owns this state?

This question is fundamental.

A process can own a user session, a WebSocket connection, a payment workflow, a device connection, a background job, or a live dashboard subscription. It can even own the state of a single moving car on a live map. This is not just implementation detail. It becomes architecture.

I have seen this most clearly in real-time operational tools built with Phoenix LiveView. The hard part was not rendering one screen or processing one request quickly. The interesting part was coordinating operational state, user interactions, real-time updates, and long-lived activities safely. When each moving entity can be modeled independently, BEAM’s process model becomes a very natural fit.

A process is not merely a concurrent task. It is often the owner of a piece of state, a protocol, a lifecycle, and a failure boundary.

This is one of the strongest reasons to consider BEAM: runtime boundaries can align naturally with domain boundaries.

Isolation by default

Processes do not share memory in the normal way. They communicate through messages.

A process owns its memory. Other processes cannot casually mutate it. To interact, they send messages.

The benefit is significant: failure and state are easier to contain.

In a BEAM system, one process getting into a bad state does not necessarily corrupt the rest of the system. It can crash. A supervisor can restart it. Other processes can continue.

This is the foundation of “let it crash”.

The phrase is often misunderstood. It does not mean “write careless code”. It means accepting that sometimes the safest recovery strategy is to terminate a faulty process and restart a clean one.

This only works when failure boundaries are small. BEAM gives you those boundaries.

Supervision as a design tool

In many systems, error handling is local: a function returns an error, a method throws an exception, a task fails, or infrastructure restarts the whole process.

OTP adds another layer: supervision.

A supervisor is a process whose job is to start, monitor, and restart child processes according to a strategy. The strategy defines what happens when a child fails. Should only that process restart? Should all related processes restart? How many restarts are acceptable before escalating?

This is not just a library convenience. It is a system design tool.

A supervision tree describes the failure topology of your application. It forces architectural questions that many systems postpone:

• What state is transient?

• What state must be persisted?

• What can be rebuilt?

• Which components are independent?

• Which components must fail together?

• What is the smallest safe restart boundary?

• Who owns recovery?

In a well-designed BEAM system, recovery is not scattered randomly across `try/catch`, retries, callbacks, and infrastructure probes. Recovery is part of the application structure.

For long-running systems, this is a serious advantage.

Mailboxes as the communication model

Every BEAM process has a mailbox. Other processes send messages to it. The receiving process chooses when and how to handle them.

This gives you a clean model for asynchronous communication. It also enables selective receive, where a process can wait for messages matching a certain pattern while leaving other messages in the mailbox.

Mailboxes make process communication explicit. Instead of shared mutable state, processes exchange messages and react to them.

This reinforces the broader model: state is owned locally, communication is explicit, and each process has a clear boundary.

Per-process garbage collection

One of the runtime’s most important choices is per-process garbage collection.

Each process has its own heap. Garbage collection usually happens per process.

As a result, a process with a small heap can be collected quickly. A process that allocates heavily pays much of its own cost. Other processes can often continue running.

This fits the broader philosophy: isolate not only state and failure, but also memory management cost.

For highly concurrent systems with many small independent processes, this can reduce latency coupling between unrelated activities.

It also gives engineers a more concrete debugging model. Instead of asking only:

Why is memory growing?

You can ask:

Which process owns this memory?

That is a much more useful operational question.

When BEAM is the right fit and when it is not

No runtime is a universal answer, and BEAM is no exception.

BEAM is especially attractive when the domain naturally contains many independent concurrent entities: real-time communication, chat, presence, collaborative applications, live dashboards, IoT device management, game servers, workflow orchestration, background jobs, WebSocket-heavy applications, event-driven state machines, and long-lived business processes.

In these systems, the hard part is often not one request. The hard part is lifecycle.

Something starts. It receives events. It owns state. It waits. It times out. It talks to other components. It may fail. It may need to restart. It may need to recover state. It may need to notify others.

This is where BEAM’s process model shines.

A useful heuristic:

The opposite is also true. If your architecture diagram is mostly stateless request/response handlers plus database calls, BEAM can still work well, especially with Phoenix, but its unique runtime advantages may matter less.

Be more cautious if your core workload is CPU-heavy computation, machine learning inference, large-scale numerical processing, video/audio processing, high-performance compression or encryption, large mutable in-memory data structures, low-level systems programming, ultra-low-latency trading-style systems, or workloads dominated by SIMD/vectorization.

Also be careful if the key libraries are much stronger outside the BEAM ecosystem, or if the team has no appetite to learn OTP deeply.

BEAM can still participate in those systems. It can coordinate them, supervise them, expose APIs around them, and manage long-running workflows. But it is often not the best place to run the hottest CPU loop.

A mature BEAM architecture often uses BEAM for orchestration and resilience, while delegating specialized computation to external services, ports, or carefully controlled native code.

This is not a failure. It is good architecture.

The traps newcomers underestimate

A few traps are especially common for engineers coming from other ecosystems. They are not syntax problems. They are runtime-model problems.

The most important one is ignoring mailbox growth. A growing mailbox usually means producers are faster than the consumer, or the consumer is blocked or overloaded. If you do not monitor mailboxes, the problem may only become visible through memory pressure, latency, or availability issues.

The second trap is turning `GenServer`s into bottlenecks. A `GenServer` processes one message at a time. If you put too much responsibility into one process, the system may look concurrent while behaving like it has a hidden global lock.

The third trap is believing supervision solves data recovery. Restarting a process gives you a clean process, not restored business state. You still need persistence, idempotency, replay, compensation, or reconstruction strategies.

The fourth trap is overusing synchronous calls. `GenServer.call` is useful, but too many synchronous dependencies create latency chains and failure propagation. Isolation disappears when every process is waiting for another one.

The fifth trap is using processes as if they were objects. A process has lifecycle, state, mailbox, failure semantics, and scheduling behavior. The better question is not “which process exposes this method?”, but “which process owns this state and failure boundary?”

The sixth trap is trusting distributed Erlang blindly. It is powerful, but it is not automatically the right choice for every service boundary. Security, network partitions, topology, latency, and operational ownership matter.

The real learning curve is not Elixir syntax. The real learning curve is OTP: supervision, process design, failure semantics, message flow, observability, releases, and production diagnosis.

Final recommendation

Do not evaluate BEAM as a drop-in replacement for your current runtime. Evaluate it as a different way to structure a system.

Before choosing it for a real project, run a small architectural spike around the runtime model, not just around syntax or framework productivity.

Model one meaningful part of your domain as processes:

• What owns the state?

• What messages cross the boundaries?

• What happens when one process crashes?

• What state must be rebuilt or persisted?

• What can be supervised safely?

• What happens if messages arrive faster than they are consumed?

• Where does CPU-heavy work belong?

If that exercise makes the design clearer, BEAM may be a strong fit.

If it makes the design feel artificial, or most of the value still lives in request handlers, database queries, and external libraries, another runtime may be a better default.

That is the practical test.

BEAM earns its place when process ownership, isolation, supervision, and recovery make the system easier to reason about — not merely because Elixir is pleasant or the runtime is elegant.

Further reading

These are good starting points if you want to go deeper into BEAM, Erlang/OTP, and the runtime ideas behind this article:

• A brief introduction to BEAM — official Erlang/OTP primer on what BEAM is and how it relates to the Erlang Runtime System.

• The BEAM Book — a deep technical reference on BEAM internals, instructions, scheduling, memory, and runtime implementation details.

• Erlang in Anger — Fred Hébert’s practical guide to operating and debugging Erlang systems in production.

• Erlang/OTP Design Principles — official documentation on OTP behaviours, supervision trees, applications, and releases.

• Supervisor behaviour documentation — official reference for OTP supervisors and restart strategies.

• Erlang Efficiency Guide — official guidance on processes, memory, binaries, and performance trade-offs.

As a software engineer coming from ecosystems like the JVM, Go, or Node.js you have a deep understanding of Site Reliability Engineering (SRE) principles and the modern observability stack. You know what it takes to operate systems at scale. When evaluating a new technology like Elixir, a critical question inevitably arises: “Can I really observe and operate this in production?” It’s a valid concern, born from experience with runtimes that can often feel like black boxes.

This article provides a direct, technically-grounded answer to that question. We will explore how Elixir offers a unique, two-pronged observability strategy: unparalleled real-time introspection thanks to its runtime design, combined with full integration into the standardized world of OpenTelemetry and Prometheus. The goal is to demonstrate that Elixir’s observability isn’t just an afterthought; it’s a powerful combination of deep, intrinsic runtime visibility and modern, standards-based instrumentation.

1. A Different Foundation: Observability by Design in the BEAM VM

To understand observability in Elixir, we must first look at its foundation. Elixir runs on the BEAM virtual machine, a core component of the Erlang Run-Time System (ERTS). The BEAM was designed from the ground up for concurrent, fault-tolerant systems, and the ability to inspect a live system is a fundamental part of its architecture, not a feature added later.

Lightweight Processes: The Core of Concurrency

The core unit of execution in an Elixir application is a “process.” Unlike heavyweight OS threads, BEAM processes are extremely lightweight. Each process is an isolated entity with its own stack, heap, and message queue (mailbox), all managed by the BEAM’s preemptive scheduler. This is fundamentally different from OS threads, which are managed by the kernel and have a much larger memory footprint. The BEAM’s ability to manage millions of lightweight processes within a single OS process is central to both its concurrency model and its observability, as the state of every single unit of work is visible to the runtime.

Built-in Introspection with Observer

The most striking feature for engineers new to the BEAM is Observer, a powerful graphical tool that is built directly into the runtime. It allows you to connect to a live Elixir node—in development or production—and inspect its internal state in real-time. This is not a third-party add-on; it’s a core capability of ERTS.

Observer provides critical insights across several areas:

• Application Inspection: Visualize the complete supervision tree of your application. This shows exactly how your processes are structured, which processes are supervising others, and how they are linked for fault tolerance.

• Process Information: Get a real-time, sortable list of every process running on the node. For each process, you can see its current memory usage, the length of its message queue, and its reduction count—a proxy for how much CPU work it has done. This is invaluable for identifying bottlenecks or memory-hungry processes instantly.

• System Overview: View detailed statistics about the BEAM itself, including scheduler utilization across all cores, memory allocator statistics for different data types, and I/O activity.

These same introspection capabilities are available programmatically through functions like erlang:process_info/2, allowing you to build custom monitoring and diagnostic tools that tap directly into the runtime’s own data.

Observer is unparalleled for interactive, live-system debugging, but it is not designed for the automated, long-term, and aggregated analysis required for production SRE practices like alerting and SLO tracking. For that, we turn to the industry-standard three pillars.

2. Bridging to the Familiar: The Three Pillars in Elixir

While Observer provides a powerful ‘point-in-time’ view into the VM, a robust observability strategy also requires historical data and distributed context. This is where the ecosystem bridges from its unique internal capabilities to the familiar ‘three pillars’ model, with the telemetry library serving as the cornerstone.

The Foundation: telemetry

Telemetry is a lightweight, universal event-dispatching library that has become the standard foundation for instrumentation in Elixir. Key libraries like the Phoenix web framework and the Ecto database wrapper use telemetry to emit standardized events about their internal operations (e.g., request timings, query performance). Other libraries can then attach to these events to generate logs, metrics, or traces. This architecture decouples instrumentation from consumption. Library authors (like the Phoenix team) can emit events without dictating how they are used, allowing operations teams to plug in any number of handlers for metrics, logging, or tracing without modifying the core library code. This is a crucial design choice for a flexible and maintainable ecosystem.

The Three Pillars of Observability

This telemetry-based approach provides a clean bridge to the three pillars of observability, which are essential for understanding the why behind a system’s behavior, not just the what.

• Logs: Discrete, timestamped records of events. They are essential for troubleshooting specific occurrences, providing the rich, detailed context needed to understand the steps leading to an error or a specific transaction.

• Metrics: Aggregated numerical representations of system health over time (e.g., request latency, error rates, CPU utilization). They are ideal for building dashboards, defining alerts on known thresholds, and analyzing historical trends.

• Traces: A detailed view of a single request’s end-to-end journey as it flows through a distributed system. Traces are crucial for diagnosing latency issues, identifying bottlenecks, and understanding inter-service dependencies in a microservices architecture.

The telemetry library provides the universal event bus that allows specialized libraries to transform raw events into the metrics and traces needed for a complete observability picture.

3. Logs: Structured Logging as a First-Class Citizen

Before discussing metrics and dashboards, it’s worth addressing logging, because this is often the first observability signal teams rely on in production—and an area where Elixir is frequently underestimated.

Elixir’s logging system is built around the Logger module, which is part of the standard library and deeply integrated with the runtime. While Logger historically emitted plain text logs by default, modern Elixir applications almost universally use structured logging, and the ecosystem makes this both straightforward and idiomatic.

Structured Logs by Default, Not by Convention

Logger supports structured, key–value metadata natively. Instead of treating logs as unstructured strings that must later be parsed, Elixir encourages attaching contextual metadata—such as request IDs, user identifiers, or domain-specific fields—directly to log events.

This metadata propagates naturally through the process model, meaning contextual information (like a request ID set at the boundary of a web request) is automatically available to all logs emitted by that process and its children. This aligns well with modern logging practices and avoids the need for thread-local hacks or manual context passing common in other ecosystems.

Flexible Encoding and Output

In production, Logger can be configured to emit logs in structured formats such as JSON, making it trivial to integrate with standard log aggregation systems (e.g., Elasticsearch, Loki, or commercial SaaS platforms). This is typically achieved by swapping the default formatter for a JSON formatter, without changing application code.

Because Logger is part of the runtime and not a third-party abstraction, this configuration is:

• Centralized

• Consistent across the ecosystem

• Decoupled from any specific log backend

This makes it easy to evolve logging strategies over time—from local development logs to fully structured production pipelines—without rewriting instrumentation.

Logs as Part of a Cohesive Observability Strategy

Crucially, logging in Elixir does not exist in isolation. Logger integrates cleanly with the broader observability stack:

• Logs can include trace and span identifiers when OpenTelemetry is enabled

• Log volume and levels can be dynamically adjusted at runtime

• Logging remains lightweight, with backpressure handled by the BEAM rather than the application

The result is a logging system that feels modern, production-oriented, and aligned with today’s expectations: structured by default, context-aware, and easy to route into both open-source and commercial observability platforms.

When OpenTelemetry is enabled, this structured logging model becomes even more powerful. Trace and span identifiers (trace_id, span_id) can be automatically injected into Logger metadata, allowing logs to be directly correlated with distributed traces. This makes it trivial to pivot from a slow or failing trace to the exact log lines emitted within that span, using standard tooling in both open-source and commercial platforms. For teams used to trace–log correlation in JVM or Go-based systems, this behavior is fully supported and idiomatic in Elixir.

4. Metrics: The Prometheus & Grafana Story

For metrics, the Elixir ecosystem has a go-to solution for integrating with the industry-standard Prometheus and Grafana stack: PromEx.

PromEx is a library designed to make exposing Prometheus-compatible metrics from an Elixir application as simple and streamlined as possible. It works by attaching its own handlers to the telemetry events emitted by your application and its dependencies, converting them into the metrics format that Prometheus scrapes.

The setup and features highlight its power and ease of use:

1. Simple Configuration: A single mix task, mix prom_ex.gen.config, generates the necessary configuration module, removing boilerplate and guesswork.

2. Effortless Phoenix Integration: PromEx.Plug is a simple plug that can be added to your Phoenix endpoint to expose a /metrics endpoint. Prometheus can then be configured to scrape this endpoint automatically.

3. Rich Ecosystem Plugins: PromEx offers a suite of pre-built plugins that provide deep visibility into the most common parts of an Elixir stack, including:

   • PromEx.Plugins.Beam (for BEAM VM metrics)

   • PromEx.Plugins.Phoenix (for web request metrics)

   • PromEx.Plugins.Ecto (for database query metrics)

   • PromEx.Plugins.Oban (for background job processing metrics)

4. Pre-built Dashboards: Crucially, each plugin comes with a tailored Grafana dashboard. This means you get meaningful, out-of-the-box visualizations for your key metrics without having to build dashboards from scratch.

5. Tracing: Embracing the OpenTelemetry Standard

For distributed tracing, the Elixir community has fully adopted OpenTelemetry (OTel), the Cloud Native Computing Foundation (CNCF) framework that provides a vendor-neutral standard for generating and collecting telemetry data.

Core Components and Instrumentation

Setting up OTel in a typical Phoenix application involves adding a few key libraries: opentelemetry_api, opentelemetry, and instrumentation-specific packages like opentelemetry_phoenix.

Instrumentation works in two primary ways:

• Automatic Instrumentation: Libraries like opentelemetry_phoenix listen for standard :telemetry events and automatically create OTel spans from them. This provides a baseline level of tracing for web requests and database queries with minimal setup.

• Manual Instrumentation: For business-logic-specific insights, you can create custom spans programmatically using functions like Tracer.with_span. This is essential for tracing business-critical logic that isn’t captured by default framework events, such as the steps within a complex financial transaction or a multi-stage data processing pipeline.

Exporting Data via the OTel Collector

The best practice for sending telemetry data in production is to use the OpenTelemetry Collector. This is a vendor-agnostic agent that receives data from your application (typically via the OTLP protocol) and can then process and export it to any number of backends. This decouples your application from the specific tracing backend (e.g., Jaeger, Zipkin, or a commercial platform), preventing vendor lock-in.

A Note on Maturity and Performance

The OpenTelemetry SDK for Elixir/Erlang is mature and widely used in production. However, for systems with very high request throughput, some performance tuning may be required. Specifically, operators may need to adjust the configuration of the batch span processor (e.g., OTEL_BSP_SCHEDULE_DELAY_MILLIS) to balance memory usage and latency, ensuring the observability layer itself does not become a bottleneck.

One important distinction to be explicit about is profiling. Unlike the JVM (JFR) or Go (pprof), the BEAM does not yet offer a ubiquitous, always-on, low-overhead continuous profiler as part of the standard production toolchain. Instead, profiling in Elixir relies on a combination of built-in tools (:eprof, :fprof, :cprof), runtime introspection, and situational diagnostics using Observer or libraries like recon. This means profiling is typically more targeted and investigative rather than continuously sampled. For many teams this is sufficient—especially when combined with strong metrics and tracing—but it is a real trade-off to be aware of for workloads where continuous CPU or allocation profiling is a hard requirement.

6. Integrating with Commercial Platforms (Datadog, New Relic, AppSignal, etc.)

Elixir applications integrate reliably with major commercial observability platforms such as Datadog, New Relic, and AppSignal. For most production systems today, the recommended and future-proof integration path is OpenTelemetry, which provides a vendor-neutral foundation for traces, metrics, and logs.

By instrumenting your application using OpenTelemetry APIs, you decouple observability concerns from any specific backend. Telemetry data is typically exported to an OpenTelemetry Collector, which then forwards it to one or more destinations—self-hosted systems like Jaeger or Prometheus, or commercial platforms such as Datadog or New Relic. Switching backends does not require changes to application code; it is a configuration concern at the Collector level.

This OTel-first approach has two important implications:

• Consistency and portability: Instrumentation remains stable even if vendors change, pricing shifts, or organizational preferences evolve.

• Reduced vendor lock-in: The application depends on open standards rather than proprietary agents or SDKs.

Some platforms also offer Elixir-specific or vendor-native integrations. AppSignal, in particular, provides a tightly integrated, Elixir-first experience with minimal setup and strong defaults. This can be an attractive option for teams that prefer a managed solution and are comfortable trading some flexibility for simplicity. However, such integrations typically couple instrumentation more closely to the vendor and make later migrations more expensive.

At a high level, the trade-off is familiar:

• Self-Hosted Open Source (Prometheus / Grafana / Jaeger): Maximum control and flexibility with no direct vendor costs. Requires operational ownership and expertise.

• Commercial SaaS Platforms: Managed infrastructure, advanced analytics, and lower operational overhead. Cost scales with usage.

In practice, many teams adopt a hybrid model: open-source tooling for core metrics and dashboards, combined with commercial platforms for tracing, alerting, or cross-service analysis. Elixir’s OpenTelemetry-based integrations support this model well.

7. The Verdict: Is Elixir Production-Ready?

So, is Elixir’s observability stack ready for the demands of modern production systems? The answer is yes. The ecosystem provides a clear two-pronged approach: deep, real-time runtime introspection via the BEAM, combined with full support for industry-standard observability practices through Telemetry, OpenTelemetry, and Prometheus-based tooling.

The BEAM’s intrinsic visibility enables operators to inspect scheduler behavior, memory usage, and individual process state directly on a live system, answering the question “what is happening right now?” with a level of precision that is difficult to achieve in many other runtimes. At the same time, standardized metrics, logs, and traces provide the historical context required for alerting, SLOs, and distributed debugging.

This contrasts with platforms where the runtime is largely opaque and observability relies primarily on sampling and post-hoc inference. In JVM or Go ecosystems, visibility is often reconstructed from external signals; in the BEAM, it is exposed directly by the runtime itself.

That said, Elixir’s observability model will not be a perfect fit for every organization. Teams that depend heavily on always-on, low-overhead continuous profiling, that are unwilling to operate BEAM-specific tooling, or that mandate vendor-specific agents may find a more natural fit elsewhere. Elixir rewards teams willing to understand the runtime it runs on—and for those teams, it offers a level of operational transparency that is difficult to replicate.

Why This Matters Now

Elixir 1.20 is not just another compiler release; it marks a pivotal moment in the language’s history. For the first time, the compiler performs sound, flow-sensitive static analysis on idiomatic Elixir code. It doesn’t just check syntax; it builds a control-flow graph to prove properties about your data, surfacing errors that previously required runtime crashes or extensive test suites to detect.

This is not about turning Elixir into a statically typed language like Java or Go. It is about evolving the “Let it Crash” philosophy into “Prove it won’t crash”. The goal is to write idiomatic Elixir that is now provably safer, easier to refactor, and self-documenting.

If you maintain a large or long-lived codebase, the way you write function heads, data structures, and guards now directly impacts the compiler’s ability to protect you.

What “Gradual Typing” Means in Elixir

Elixir’s type system is built on three pillars:

• Gradual: Types are optional. The system embraces the dynamic() type, allowing valid runtime code to exist even if static types can’t be proven yet.

• Set-theoretic: Types are treated as sets of values. integer() or atom() is a union set. integer() and atom() is an empty set (because no value can be both).

• Flow-sensitive: The compiler learns from your code’s control flow. A guard or a pattern match isn’t just a runtime check; it is a fact that refines the type of a variable for the rest of the block.

The Critical Distinction: Unlike Dialyzer, which uses “Success Typing” (optimistically assuming code is valid unless proven otherwise), the new system is sound. If it identifies a type violation (e.g., an empty intersection like String AND Integer), it guarantees that the code is buggy.

The Mental Model: Strong Arrows

The most important concept to internalize is the strong arrow.

In many dynamic languages, operators accept any type and return any type. In Elixir’s new system, a “strong arrow” is a function or operator that the compiler knows will crash if given input outside its domain.

Examples:

• String.upcase/1 is a strong arrow (crashes on non-strings).

• The + operator is a strong arrow (crashes on non-numbers).

The Superpower: Backwards Inference

When the compiler sees x + 1, it infers backwards that x must be a number. You don’t need to annotate x; the usage dictates the type.

Takeaway: The more strong arrows you use (via guards, pattern matching, and kernel functions), the more the compiler learns about your code automatically.

Evolution of the Type System (v1.17 → v1.20)

Elixir 1.17: Detecting Logical Fallacies

This release introduced the set-theoretic core. Its biggest impact was detecting impossible comparisons derived from pattern matching.

Example: The compiler spots when a variable constrained by a match is compared against a disjoint type.

5 > "hello"

It also emits warnings when you do structural comparison between structs. The most common cases are comparing Date and DateTime.

my_date < ~D[2010-04-17]

Elixir 1.18: Function Boundaries

Inference extended across function calls, alongside gradual inference of patterns and return types.

The Check: The compiler can warn if you call a function with an incorrect pattern. Example: User.drive({:ok, %User{}}, car_choices) instead of User.driver(%User{}, car_choices). It can also warn you about clauses that will never match in case statements.

Impact: Function heads start acting as strict type filters. The compiler can detect dead code in case statements.

Elixir 1.19: Anonymous Functions & Protocols

Type checking expanded to:

• Anonymous Functions: Although they default to a dynamic() input, Example: fn x -> x + 1 end is now inferred as: dynamic() -> number(), thanks to strong arrows inside the body, the compiler infers x as a number inside the function and guarantees a numeric return

• Protocols: Interpolating a struct that doesn’t implement String.Chars into a string ("#{user}") now warns at compile time.

Elixir 1.20: The “Completeness” Release

Currently in release candidate status, v1.20 closes the loop. It brings inference to the remaining “blind spots” of the language:

• Universal Constructs: receive, try/catch, with and for comprehensions are now fully understood by the inference engine.

• General Maps: Previous versions focused on atom-keyed maps (struct-like). v1.20 adds support for maps with arbitrary keys and operations like Map.put and Map.delete.

How to Write Elixir That the Compiler Understands

To maximize the benefits of this system, you don’t need to learn a new syntax, but you should adopt specific idiomatic patterns.

1. Require Strict Struct Updates

One of the hard deprecations introduced in v1.19 involves the struct update syntax.

The Old Way (Unsafe):

Elixir

def update(user, name) do
  # Warning: user is 'dynamic', compiler can't verify keys
  %User{user | name: name} 
end

The New Idiomatic Way: You must provide "evidence" that the variable is a struct before updating it.

Elixir

def update(%User{} = user, name) do
  # Compiler now KNOWS user is %User{}
  %{user | name: name}
end

Note: Using the map update syntax %{...} after a match is now preferred as it removes redundancy while retaining type safety.

2. Pattern Match Structs on Function Clauses

Adding struct type pattern matching in function clauses will help the compiler detect calls with incorrect parameters and help you avoid typo errors when accessing struct fields.

defmodule User do
  def full_name(%User{} = user) do
    # compiler will emit warnings if you access
    # an non-existing property, Example: User.neim
    "#{user.name} #{user.surname}"
  end
end

# This call will emit a warning
User.fullname({:ok, %User{})

3. Use Guards to “Narrow” Types

Treat guards as type assertions. A variable starts as term() (the set of all values). Every guard intersects that set.

Elixir

def normalize(s) when is_binary(s) do
  # Inside this block, 's' is strictly binary().
  # Calling String.trim(s) is provably safe.
  String.trim(s)
end

Tip: v1.20+ can infer types from complex boolean guards like is_integer(x) or is_float(x).

4. Prefer Structs Over Maps

Generic maps are the “least informative” structure. They do not restrict the keys or the types of values they can contain, and therefore you need to do defensive programming to ensure they have the expected keys.

• Map: Keys are unconstrained. Shape is implicit.

• Struct: Keys are defined. Shape is explicit. Whenever possible, use a struct. It transforms a data container into a type carrier that propagates safety guarantees throughout your system.

Should Teams Still Use Dialyzer?

Yes, but its role has shifted.

Dialyzer uses Success Typing and excels at cross-module and library boundary checks, enforcing @spec contracts and catching inconsistencies the compiler doesn’t see.

The compiler’s new type system is sound and flow-sensitive, catching local logic errors, unreachable code, and invalid assumptions in real time.

Together, they complement each other: the compiler ensures local correctness, while Dialyzer validates global contracts. Teams should continue writing @specs to retain these benefits and ease future transitions to compiler-enforced signatures.

The Road Ahead (Next ~15 Months)

The “Inference Era” concludes with v1.20. The next phase involves explicit type features:

• Inference across clauses and dependencies (RC3 - May 2026): Function calls into external libraries (like Phoenix or Ecto) will be type-checked.

• Typed Structs (v1.21+): A way to define the types of struct fields natively (e.g., defstruct name: string()).

• Type Signatures: Eventually, we will get a syntax to express function contracts that the compiler enforces, replacing @spec for pure static analysis.

Closing Thoughts

Elixir is not becoming a rigid, statically typed language. It is becoming a language where idiomatic code is safe code.

By writing clear Elixir: matching on structs, using guards, and relying on standard library functions, you enable the compiler to act as a second pair of eyes. It validates your assumptions as you type, catching logical errors early and reducing the class of bugs that would otherwise surface in production.

This shift fundamentally changes how we trust and evolve Elixir systems. Large codebases become easier to refactor, APIs become more self-documenting, and correctness improves without sacrificing the language’s flexibility or ergonomics. Elixir is not changing its philosophy, it is finally giving the compiler enough information to enforce it.

If you are new to the Elixir ecosystem, or evaluating it for your next project, you may wonder what tooling exists for the tasks every team needs: building, testing, debugging, documentation, dependency management, and observability. You may also wonder how mature these tools are in practice.

Why tooling matters

Tooling is a key factor when evaluating a programming language. Beyond syntax or performance, it determines how efficiently teams can build, test, debug, and operate systems over time. Today, a language is expected to provide more than a compiler: formatting, testing, documentation, dependency management, and observability are part of the baseline.

In Elixir, tooling is a deliberate part of the language design and is strongly influenced by the runtime execution model. Elixir runs on a virtual machine built for massive concurrency, fault isolation, and long‑running systems. This model does not align well with step‑through debugging assumptions common in other ecosystems. As a result, Elixir tooling tends to prioritize observability and runtime safety over developer convenience.

Rather than relying on a large collection of third‑party tools, Elixir provides a small but deeply integrated core toolset. Tools like mix, iex, ExUnit, and Logger work together out of the box and establish consistent conventions across projects. These choices come with explicit trade‑offs, but they scale well for concurrent, long‑running applications.

In short, Elixir’s tooling does not try to hide complexity; it makes the important complexity visible.

Elixir core tooling (included by default)

The following tools are included by default and cover most workflows required to build and operate Elixir applications.

Build tool

Mix is Elixir’s build tool and the backbone of the development workflow. It is used to create new projects, manage dependencies, compile code, run applications and tests, and build releases. Rather than delegating these responsibilities to separate tools, Mix provides a single, consistent interface for the entire lifecycle of an Elixir project.

Mix is extensible through custom tasks, allowing both applications and libraries to integrate their own workflows directly into the build system. This extensibility is widely used across the ecosystem and contributes to a uniform developer experience.

Mix also includes built‑in tooling such as mix format, which enforces a standard code style across projects. The formatter is extensible, enabling libraries to define additional rules while preserving a shared baseline, reducing stylistic debates and improving code readability.

REPL

IEx is Elixir’s interactive shell and a central part of the development workflow. It allows developers to execute Elixir code interactively, explore APIs, and inspect runtime behavior.

When started with iex -S mix, it loads the current project and its dependencies, making it useful not only for experimentation but also for debugging and inspection in real applications. IEx provides a rich set of helpers, such as h/1 to display documentation for modules and functions, and i/1 to inspect data types and structures.

By integrating documentation, introspection, and runtime evaluation, IEx encourages an exploratory style of development and short feedback loops.

Testing

ExUnit is the unit testing library included by default in Elixir. It can run tests in parallel using the runtime’s native concurrency, which can significantly improve test suite performance. This parallelism, however, requires tests to be isolated and free of shared state in order to avoid flaky behavior.

At first glance, ExUnit appears simple, but it provides a powerful and flexible set of features that scale well as projects grow:

• Documentation tests: Tests can be defined directly in module documentation to ensure that code examples remain correct and up to date.

• Tags for modules and tests: Tags allow filtering which tests are executed, enabling workflows such as running only slow, integration, or focused test subsets.

• Parameterized tests: The same test logic can be executed with different inputs, although this feature currently operates at the module level.

• Log capture: Logs can be captured and asserted against, which is particularly useful when testing error cases or observable behavior.

• Temporary directories: Tests tagged with :tmp_dir automatically receive an isolated temporary directory, simplifying the testing of file system interactions.

Overall, ExUnit encourages a testing style based on isolation, determinism, and fast feedback.

Logging

Elixir includes a built‑in logging system, Logger, designed for highly concurrent, long‑running systems where logging must never become a source of instability.

Logger uses an asynchronous architecture, ensuring that application code does not block on I/O operations. It also applies back‑pressure when handling log writes, preventing excessive memory usage and avoiding system crashes under high load.

Logger provides several features that support production‑grade observability:

• Standard log levels and compile‑time purging: Lower‑level logs can be removed at compile time to reduce runtime overhead.

• Process‑based metadata: Metadata can be attached at the process level, making it easier to correlate logs with requests, jobs, or background work.

• Pluggable backends: Log generation is decoupled from log output, allowing logs to be written to the console, files, or external systems.

• Structured logging: Log formats can be customized, including structured formats like JSON.

• Runtime configuration: Logging behavior can be adjusted at runtime without redeploying the application.

Documentation

In Elixir, documentation is treated as a first‑class citizen. Modules and functions can be documented directly in the source code using attributes such as @moduledoc and @doc, making documentation part of the public API rather than an afterthought.

Documentation is immediately accessible from the interactive shell through helpers like h/1, encouraging developers to explore and understand code from within iex.

Elixir’s documentation ecosystem is supported by ExDocs, a documentation generator capable of producing static websites from project documentation. ExDocs supports Markdown and Mermaid diagrams, enabling rich explanations to live alongside the code.

Templating

EEx is Elixir’s templating engine and a foundational building block for rendering content. Rather than interpreting templates at runtime, EEx compiles templates into Elixir bytecode, improving performance and allowing template errors to be detected earlier.

EEx is designed to be extended through custom engines. A notable example is Phoenix’s heex engine, which builds on EEx to provide safer HTML rendering and additional compile‑time checks. This approach enables strong correctness guarantees while keeping templating tightly integrated with the language.

Package management

Elixir uses Hex as its package management system, shared across Erlang, Elixir, and Gleam. Libraries are typically published to Hex and declared in the mix.exs project configuration file, where versions and constraints are explicitly defined.

Dependency resolution is tightly integrated with Mix, producing a lockfile that ensures deterministic and reproducible builds across environments. Dependencies can also be fetched directly from GitHub or GitLab when needed.

Developer experience

Language Server

For some time, Elixir had multiple language server implementations, which led to a fragmented developer experience. To address this, an official language server team was formed in 2024 with the goal of unifying these efforts. The result was a new language server, released in 2025 under the name Expert.

Expert combines strengths from previous implementations and includes native integration with tools such as Credo and Dialyzer. At the time of writing, it does not yet support debugging with breakpoints, which remains available in ElixirLS. As a result, Expert represents the long‑term direction for Elixir’s language tooling, while ElixirLS may still be preferred by developers who rely heavily on debugger support.

Debugging

Elixir provides several debugging tools by default, but its approach differs from traditional step‑through debugging. Debugging is primarily based on inspection, tracing, and observability rather than pausing execution and stepping through code line by line.

For day‑to‑day debugging, Elixir favors explicit inspection through tools such as IO.inspect/2 and dbg/2. For interactive debugging, IEx supports mechanisms like Pry and breakpoints. For system‑level inspection and performance analysis, tools such as Observer and built‑in profiling tasks are commonly used.

This approach emphasizes understanding system behavior through observation and instrumentation, which scales better for concurrent, long‑running applications.

Advanced and optional tools

Static analysis

Dialyzer is a static analysis tool for Elixir and Erlang that helps detect type inconsistencies, unreachable code, and certain classes of bugs by analyzing function signatures and typespecs. It is typically used via Dialyxir, which integrates it into the Mix workflow.

Dialyzer is optimistic: it only reports issues when it can prove that the code will fail at runtime. This results in no false positives, at the cost of potential false negatives. While error messages can be cryptic and the initial analysis slow, Dialyzer provides a valuable safety net in large or long‑lived codebases.

Credo focuses on promoting good practices and consistency rather than runtime correctness. Its rules cover areas such as refactoring opportunities, software design, readability, and consistency. Credo emphasizes education by explaining the reasoning behind each rule, making it particularly useful for teams and less experienced developers.

Sobelow is a static analysis tool designed to detect common security vulnerabilities in Phoenix web applications, such as XSS, SQL injection, and CSRF. It is framework‑aware and most effective as a preventive measure during development and code review.

Benchmarking

Benchee is the standard benchmarking tool in the Elixir ecosystem. It enables statistically meaningful comparisons between different implementations by accounting for variability and measuring execution time and memory usage.

Benchmark results can be exported in formats such as HTML, JSON, or CSV, making it easier to share findings or track performance changes over time.

Maturity and trade‑offs

The Elixir tooling ecosystem is mature, not because it offers exhaustive automation, but because it prioritizes stability, cohesion, and operational correctness.

Core tooling is deeply integrated and evolves conservatively, favoring backward compatibility. Dependency management is deterministic and predictable. Observability and debugging tools are designed around concurrency and live systems.

Other areas are still evolving. Language tooling continues to improve, refactoring automation remains limited, and typing support is progressing gradually. Experimental work is also exploring new ideas, such as structured LLM‑assisted development, though these efforts are not yet part of the standard tooling stack.

These characteristics reflect deliberate trade‑offs: observability over step‑through debugging, soundness over completeness, cohesion over customization, and operational focus over IDE‑centric workflows.

Who this tooling model works best for

Elixir’s tooling model is particularly well suited for teams building systems where correctness, operability, and long‑term maintenance matter more than short‑term developer convenience.

It tends to work best for:

• Backend and distributed systems teams building APIs, event‑driven services, and long‑running processes.

• Organizations operating production systems continuously, where observability, fault tolerance, and safe runtime behavior are critical.

• Teams that value conventions and shared workflows over highly customized setups, reducing cognitive load and decision fatigue.

• Codebases expected to evolve over years, where conservative tooling evolution and backward compatibility are advantages rather than constraints.

Teams that rely heavily on rich IDE automation, extensive refactoring tools, or step‑by‑step debugging may find Elixir’s tooling model less familiar. In those cases, the emphasis on inspection, testing, and observability requires a shift in habits rather than additional tooling.

Conclusion

Elixir’s tooling stands out not because it tries to do everything, but because it is intentionally cohesive. The core tools cover the full development lifecycle with minimal setup, clear conventions, and strong integration with the runtime model.

Its limitations—particularly around IDE ergonomics and automated refactoring—are real, but they are the result of deliberate trade‑offs rather than neglect. Elixir favors explicit behavior, operational clarity, and runtime safety, even when that means asking more from developers upfront.

For teams building reliable, long‑running systems, this tooling model can be a strength rather than a weakness. Evaluating Elixir effectively means understanding not only what its tools provide, but also the philosophy that shapes them.

Nature of software complexity

Software complexity refers to any aspect of a system’s structure that makes it difficult to understand and modify.

Complexity is determined by the activities that are most common. If some parts of a system are very complicated but are almost never touched, they have little impact on the system’s overall complexity. Therefore, isolating complexity in a place where it will rarely be seen is almost as effective as eliminating it entirely.

It is also important to remember that complexity is more apparent to readers than to writers. If a piece of code seems simple to its author but complex to other developers, then it is complex.

Symptoms of Complexity

Change Amplification

A system suffers from change amplification when a simple change requires modifications in many different places.

Cognitive Load

Cognitive load refers to how much a developer needs to know in order to complete a task. Some abstractions increase complexity because they require extensive background knowledge to make even small changes.

In some cases, an approach that requires more lines of code is actually simpler because it reduces cognitive load.

Unknown Unknowns

Unknown unknowns arise when it is not obvious which pieces of code must be modified to complete a task, or what information a developer needs. This is the most severe manifestation of complexity, as it often means that required changes are only discovered after a bug appears.

This situation sometimes depends on subtle design decisions that were never documented.

One of the most important goals of good design is to make a system obvious.

Causes of Complexity

Dependencies

A dependency exists when a piece of code cannot be understood or modified in isolation. One of the main goals of software design is to reduce the number of dependencies and to make the remaining ones as simple and obvious as possible.

Obscurity

Obscurity occurs when important information is not clear or visible. Common causes include:

• Important information that is not obvious, such as overly generic variable names (for example, time).

• Inconsistencies, such as using the same variable name for different purposes.

• Inadequate documentation.

• Design Issues: When a system is clean and obvious, it requires less documentation. Poor design increases obscurity and, as a result, complexity.

Complexity Is Incremental

Complexity grows over time through the accumulation of many dependencies and obscurities, which makes it increasingly difficult to control. To slow this growth, teams must adopt a zero-tolerance philosophy toward unnecessary complexity.

Modules should be deep

Modular design is design the systems so that developers only need to face a small fraction of the overall complexity at any given time.

Modular design

Software systems are decomposed into a collection of modules that are relatively independent. Modules must work together by calling each others’s functions or methods, which create dependencies between the modules.

To identify the dependencies we think in the modules as a interface and a implementation. The interface is everything that a developer must know to use the module. The implementation is the code that carries the promises made by the interface.

The best modules are those whose interfaces are much simpler than their implementations.

The interface to a module contains two kinds of information: formal and informal. The formal interface for a method is its signature, and the informal is the rest of the information that a developer needs to know to use a module, which are usually just described using comments.

Abstractions

An abstraction is a simplified view of an entity, which omits unimportant details.

Each module provides an abstraction. The interface presents a simplified view of the module’s functionality. An abstraction can go wrong in two ways:

• It can include details that are not really important, which make the abstraction more complicated that necessary.

• It can omit details that are really important, this result in obscurity.

So, the key to design abstractions is to understand what it’s important.

Deep modules

The best modules are those that provide powerful functionality yet have simple interfaces. A deep module is a good abstraction because only a small fraction of its internal complexity is visible to its users.

Shallow modules

A shallow module is one whose interface is relatively complex in comparison to the functionality that it provides, it is no simpler to think about the interface than to think about the full implementation.

Classitis

Usually, it’s recommended that the classes and the methods should be small, the problem of this approach is that this generate a large number of shallow classes, they are individually simple, but they add a lot of complexity to the system, and also result in a more verbose programming style.

Interfaces should be designed to make the common case as simple as possible.

Information hiding (and leakage)

Information hiding

One of the most important techniques for achieving deep modules is information hiding. The idea is that each module should encapsulate a few pieces of knowledge, which represents design decisions. The knowledge is embedded in the module’s implementation but doesn’t appear in its interface, so it is not visible to other modules. It usually consists of details about how to implement some mechanism.

The hidden information includes data structures and algorithms related to the mechanism. It can also include lower-level details such as the size of a page, and it can include higher-level concepts that are more abstract, such as an assumption that most files are small.

It simplifies the interface of a module and reduces the cognitive load on developers who use the module.

Information leakage

Information leakage occurs when a design decision is reflected in multiple modules. This creates a dependency between the modules: any change to that design decision will require changes to all of the involved modules.

Information leakage is one of the most important red flags in software design.

Temporal decomposition

In temporal decomposition, the structure of a system corresponds to the time order in which operations will occur.

When designing modules, focus on the knowledge that’s needed to perform each tasks, not the order in which tasks occur.

Information hiding can often be improved by making a class slightly larger.

Default values of parameters illustrate the principle that interfaces should be designed to make the common case as simple as possible. They are also an example of partial information hiding.

General-Purpose modules are deeper

Over-specialization usually introduces complexity without providing significant additional functionality, and it is more of a tactical investment.

One of the best ways to produce a deep API is to make it general-purpose. This allows it to address a broad range of problems and typically results in better information hiding.

One of the most effective ways to simplify code is to eliminate special cases, so that the common-case code also handles edge cases.

When creating a general-purpose solution, it may include facilities that are never actually needed. The sweet spot is to implement new modules in a somewhat general-purpose manner. A module’s functionality should reflect current needs, but its interface should not. The interface should be general enough to support multiple use cases.

Over-specialization cannot be completely eliminated, but it should be pushed upward and downward, into the application and infrastructure layers.

One of the most important aspects of software design is determining who needs to know what, and when. When details are important, it is better to make them explicit and as obvious as possible.

Different Layer, Different Abstraction

Software system are composed of layer, where higher layers use the facilities provided by lower layers. Each layer provides a different abstraction from the layers above and below it. If adjacent layers have similar abstractions, this is a red flag that suggest a problem with the class decomposition.

Pass-through methods

A pass-through method is one that just invoke another method with the same API. This indicates a not clean division of responsibilities and make the classes shallower. Introduce complexity but don’t add functionality to the system. The solution is to refactor the classes so that each class has a distinct and coherent set of responsabilities.

When is interface duplication OK?

Having methods with the same signature is not always bad. The imporant thing is that each new method should contribute significant functionality. One example is a dispatcher. A dispatcher is a method that uses its arguments to select one of several other methods to invoke.

Decorators

The decorator design pattern encourages API duplication across layers. The motivation is separate special-purpose extensions of a class from a generic core. Decorators tend to be shallow. Before creating a decorator consider the following alternatives:

• Add the new functionality directly to the underlying class.

• Merge it with the use case.

• Merge with an already existing decorator.

• Could be implemented as stand-alone?

• Is it a wrapper to translated a external class whose interface cannot be modified, but it must conform a different interface?

Interface versus implementation

The interface of a class should normally be different from its implementation: the representations used internally should be different from the abstractions that appear in the interface.

Pass-through variables

Another form of API duplication across layers is a pass-through variable, which is a variable that is passed down through a long chain of methods. They add complexity because they force all of the intermediate methods to be aware of their existence, even though the methods have no use for the variables.

One way of solve this is introduce a context object which stores all of the application’s global state. It will probably be needed in many places, so it can potentially become a pass-through variable. Without discipline, a context can turn into a huge grab-bag of data that creates non obvious dependencies throughout the system. They may also have thread-safe issues, so the best option is that variables of a context should be inmutable.

Pull complexity downwards

Most modules have more users than developers, so it is better for the developers to suffer than the users, what means than it is more important for a module to have a simple interface than a simple implementation.

Configuration parameters provide an easy excuse to avoid dealing with important issues and pass them on to someone else. When you do create configuration parameters, see if you can provide reasonable defaults, so users will only need to provide values under exceptional conditions.

Taking it too far

An extreme approach would be to pull all of the functionality of the entire application down into a single class, what clearly doesn’t make sense. You should pull down complexity if:

• It is closely related to the class’s existing functionality.

• It will result in simplification elsewhere in the application.

• Simplifies the class’s interface.

While it’s difficult to get exact figures for value and cost, asking the following questions will give you insight into the potential expense of a bit of code:

How difficult was it to write? How hard is it to understand? How expensive will it be to change?

DRY principle says:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

If you’ve duplicated a bit of code in many places, the DRY principle tells you to extract the duplication into a single common method and then invoke this new method in place of the old code.

If the code isn’t open yet, you should first refactor it to make it open, and once done you can add the new code.

To refactor to make it open, you should be guided by the code smells.

So, when should you refactor:

The rule of three The third time you do something similar, you should refactor it.

When you add a function You want to add a feature to an existing code you have written or have been written by someone else.

Refactoring is a technique for restructuring code in a way that you improve the design, but don’t change the its external behaviour.

It is done applying a serie of small transformations to the code (called a “refactor”), and using test to ensure the external behaviour never changes.

Thanks that each refactor is small, if something goes wrong and a test fails, is easy go back, undo the changes, minimizing the probability that a bug can be introduced.

Zero Bug Software Development is a policy to archive an state of zero known bugs. The first step to reach this state is label the issues using a very strict classification:

Critical issues: The user is not receiving the value that is supposed to receive. You should stop what you are doing and fix it inmediatelly. Bugs: The app is not working as expected but the users can receive the value that is supposed to.

The flocking rules are an small set of rules for refactoring code. The idea is make small incremental changes that allows you obtein precise error messages when something goes wrong, so if you find and error, you can revert it and make a smaller one. The steps are the following:

Select the things that are most alike. Find the smallest difference between them. Make the simplest change that will remove that difference.

So what to do then? The answer is less. Do less than your competitors to beat them. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of oneupping, try one-downing. Instead of outdoing, try underdoing.

Less features Less options/preferences Less people and corporate structure Less meetings and abstractions Less promises External links 37 Signals - Getting Real: Build Less Related notes What is refactoring.