--- title: Anti-Antipatterns in Elixir Library Guidelines | daily.dev description: A critical deconstruction of the official Elixir library guidelines' anti-patterns section, arguing that each of the nine declared anti-patterns has legitimate... canonical: https://daily.dev/posts/anti-antipatterns-in-elixir-library-guidelines-bdnl8ndhb twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Anti-Antipatterns in Elixir Library Guidelines | daily.dev og:description: A critical deconstruction of the official Elixir library guidelines' anti-patterns section, arguing that each of the nine declared anti-patterns has legitimate... og:url: https://daily.dev/posts/anti-antipatterns-in-elixir-library-guidelines-bdnl8ndhb og:image: https://api.daily.dev/og/posts/bdNL8NdHb.png og:image:alt: Anti-Antipatterns in Elixir Library Guidelines og:image:width: 1200 og:image:height: 630 og:locale: 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 for an Elixir library to use Application.get_env instead of passing options explicitly? Application configuration is justified when a system needs uniform, system-wide defaults that can be set once in config/config.exs while still allowing per-call overrides. This is especially useful in umbrella projects where many sub-applications share dependencies like a markdown parser, avoiding the need to thread configuration options through dozens of call-stack layers. _Explore more perspectives on Elixir configuration patterns and library design trade-offs on daily.dev._ ### Why would an Elixir library use throw/catch or exceptions instead of ok/error tuples for internal control flow? Exceptions or throw/catch act as a clean, non-local exit for deeply nested recursive operations, such as a fifteen-level-deep AST or tree parser. Propagating an {:error, reason} tuple back up through every stack frame requires wrapping each recursive step in a with block, burying the core algorithm in error-plumbing boilerplate; throwing unwinds the stack directly to the public API boundary where it converts back to a clean tuple. _Developers weighing error-handling strategies in Elixir can find more deep dives like this on daily.dev._ ### Why do some Elixir libraries define modules inside another library's or the standard library's namespace despite guideline warnings against it? Placing modules in a target namespace is the whole point for drop-in polyfills and compatibility layers, such as a backwards-compatibility shim for a deprecated OTP module or a telemetry patching library like Telemetria. This lets existing applications adopt the library without modifying every call site, and supports protocol consolidations or global dispatchers that third-party plugins hook into. _Library authors debating namespace conventions can browse related Elixir architecture 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 - [Building AI Agents? Here Are Some Anti-Patterns to Avoid.](https://daily.dev/posts/building-ai-agents-here-are-some-anti-patterns-to-avoid--3lg9j0mta) · Machine Learning Mastery · 1 upvotes · 0 comments - [When Design Patterns Become Rituals](https://daily.dev/posts/when-design-patterns-become-rituals-cnr1hrkja) · We Are .NET · 78 upvotes · 9 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) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Anti-Antipatterns in Elixir Library Guidelines","url":"https://daily.dev/posts/anti-antipatterns-in-elixir-library-guidelines-bdnl8ndhb","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/anti-antipatterns-in-elixir-library-guidelines-bdnl8ndhb"},"datePublished":"2026-08-09T19:28:00.859Z","dateModified":"2026-09-14T06:05:27.825Z","description":"A critical deconstruction of the official Elixir library guidelines' anti-patterns section, arguing that each of the nine declared anti-patterns has legitimate...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/c9175e37abe3d459df289e00204abaf9?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/c9175e37abe3d459df289e00204abaf9?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Beam Bloggers Webring","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Beam Bloggers Webring","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/e1c9c007266d44759881a7591ba181f2","url":"https://daily.dev/sources/beambloggers"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/anti-antipatterns-in-elixir-library-guidelines-bdnl8ndhb","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"authentication,elixir,erlang","timeRequired":"PT8M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Beam Bloggers Webring","item":"https://daily.dev/sources/beambloggers"},{"@type":"ListItem","position":3,"name":"Anti-Antipatterns in Elixir Library Guidelines"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/anti-antipatterns-in-elixir-library-guidelines-bdnl8ndhb#faq","mainEntity":[{"@type":"Question","name":"When is it acceptable for an Elixir library to use Application.get_env instead of passing options explicitly?","acceptedAnswer":{"@type":"Answer","text":"Application configuration is justified when a system needs uniform, system-wide defaults that can be set once in config/config.exs while still allowing per-call overrides. This is especially useful in umbrella projects where many sub-applications share dependencies like a markdown parser, avoiding the need to thread configuration options through dozens of call-stack layers. Explore more perspectives on Elixir configuration patterns and library design trade-offs on daily.dev."}},{"@type":"Question","name":"Why would an Elixir library use throw/catch or exceptions instead of ok/error tuples for internal control flow?","acceptedAnswer":{"@type":"Answer","text":"Exceptions or throw/catch act as a clean, non-local exit for deeply nested recursive operations, such as a fifteen-level-deep AST or tree parser. Propagating an {:error, reason} tuple back up through every stack frame requires wrapping each recursive step in a with block, burying the core algorithm in error-plumbing boilerplate; throwing unwinds the stack directly to the public API boundary where it converts back to a clean tuple. Developers weighing error-handling strategies in Elixir can find more deep dives like this on daily.dev."}},{"@type":"Question","name":"Why do some Elixir libraries define modules inside another library's or the standard library's namespace despite guideline warnings against it?","acceptedAnswer":{"@type":"Answer","text":"Placing modules in a target namespace is the whole point for drop-in polyfills and compatibility layers, such as a backwards-compatibility shim for a deprecated OTP module or a telemetry patching library like Telemetria. This lets existing applications adopt the library without modifying every call site, and supports protocol consolidations or global dispatchers that third-party plugins hook into. Library authors debating namespace conventions can browse related Elixir architecture discussions on daily.dev."}}]} ```