--- title: "Anti-Antipatterns in Elixir Library Guidelines" url: https://daily.dev/posts/anti-antipatterns-in-elixir-library-guidelines-bdnl8ndhb source_url: https://rocket-science.ru/hacking/2026/08/09/anti-antipatterns-in-elixir-libraries type: article source: "Beam Bloggers Webring" published: 2026-08-09T19:28:00.859Z updated: 2026-08-09T19:28:32.555Z tags: ["authentication", "elixir", "erlang"] reading_time: 8 upvotes: 0 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Anti-Antipatterns in Elixir Library Guidelines **[Beam Bloggers Webring](https://daily.dev/sources/beambloggers)** · 8 min read · 0 upvotes · 0 comments ## Summary A critical deconstruction of the official Elixir library guidelines' anti-patterns section, arguing that each of the nine declared anti-patterns has legitimate use cases. The post walks through all nine rules — including avoiding application configuration, compile-time config, exceptions for control flow, macros, and unsupervised processes — and provides concrete engineering scenarios where breaking each rule is not just acceptable but necessary. The core argument is that guidelines are useful defaults for beginners, not universal laws, and that understanding why a rule exists gives developers the authority to break it when trade-offs demand it. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### When is it acceptable to use Application.get_env in an Elixir library instead of passing explicit options? Using Application.get_env is justified when you need system-wide defaults across many modules, such as in umbrella projects where the same configuration (e.g., a markdown plugin) must apply across fifteen sub-applications. Passing explicit opts through forty layers of call stacks turns every intermediate module into a passthrough for keys it doesn't care about. Application config lets operators define defaults once while still allowing per-call overrides. _Elixir library authors navigating this trade-off share patterns and war stories on daily.dev._ ### Why would you use compile-time application configuration in Elixir despite the official guidelines warning against it? Compile-time configuration via module attributes (e.g., @http_client Application.fetch_env!(...)) is justified in two scenarios: hot loops running millions of times per second where runtime Application.get_env/3 lookups add measurable overhead, and macro-based code generation where AST structures must be constructed at compile time. In the latter case, runtime lookup is literally impossible — the AST must exist before the program runs. _Developers optimizing Elixir library performance track discussions like this on daily.dev._ ### When should I use throw/catch instead of {:ok}/{:error} tuples in Elixir? throw/catch (or a dedicated exception rescued at the top-level boundary) is appropriate in deeply nested recursive algorithms, such as AST traversals or tree parsers fifteen levels deep. Propagating {:error, reason} back through 14 stack frames requires wrapping every recursive step in with blocks, burying the core algorithm under error-plumbing boilerplate. throw unwinds the stack immediately to the public API boundary, which still returns a clean {:error, reason} tuple to callers. _Elixir engineers debating control-flow patterns in library internals find relevant discussions on daily.dev._ ## Similar posts on daily.dev - [Design Patterns Suck](https://daily.dev/posts/design-patterns-suck-kei3cx9df) · iamluminousmen · 1 upvotes · 0 comments --- Tags: [#authentication](https://daily.dev/tags/authentication), [#elixir](https://daily.dev/tags/elixir), [#erlang](https://daily.dev/tags/erlang) [View this post on daily.dev](https://daily.dev/posts/anti-antipatterns-in-elixir-library-guidelines-bdnl8ndhb)