# Let libraries be libraries

**URL:** <https://forum.elixirforum.com/t/let-libraries-be-libraries/75921>\
**Category:** Blog Posts\
**Tags:** best-practices, anti-patterns, blogs-by-jola\
**Created:** [July 7, 2026, 12:50pm UTC](https://forum.elixirforum.com/t/let-libraries-be-libraries/75921 "2026-07-07T12:50:38Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![GrammAcc](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/grammacc/32/40380_2.png) [@GrammAcc](https://forum.elixirforum.com/u/GrammAcc)\
**Post date:** [July 7, 2026, 10:55pm UTC](https://forum.elixirforum.com/t/let-libraries-be-libraries/75921/6 "2026-07-07T22:55:00Z")

</div>

I agree.

I love how OTP primitives make complex state management explicit and easy to follow without dictating how the project needs to be structured. Dependencies starting their own supervision trees could be more convenient, but as soon as I need to debug something or want to implement a usage pattern the library designer didn’t foresee, things could get a lot less convenient. I can understand the desire to make a library super easy to use for the “common” cases, but that usually comes at the expense of making it more cumbersome to use in other scenarios. And most real-world problems seem to fall into the “other” category in my experience.

I also prefer it when I can put config into the initial state in the child spec as opposed to having a 10k line `config.exs` file. It keeps the process orchestration and configuration in one place. And if I did want to have the dependency’s config in the `config.exs`, I could still add a config key for it myself and just call `Application.fetch_env!/2` in the child spec. 🙂

---

_[View the full topic](https://forum.elixirforum.com/t/let-libraries-be-libraries/75921)._