Ash Framework – Model your domain, derive the rest

Production experience & learning curve

• Several commenters report running Ash in production (sometimes replacing large NestJS or legacy apps) and describe big reductions in boilerplate, especially around GraphQL, authorization, and complex workflows.
• Others tried Ash for weeks, then restarted in plain Phoenix and were faster within days. They cite a “brutal” learning curve, cryptic errors, and poor early documentation.
• One team using Ash for ~9 months says productivity dropped and most devs dislike working in Ash, though they concede it enforces a standardized data layer.

What Ash is and where it fits

• Many readers are confused by the homepage: it’s not clear what Ash actually does or how it compares to Phoenix/Django/Rails.
• Core description offered in the thread: a declarative application/domain framework that sits between DB (Ecto) and web layer (Phoenix, or other UIs).
• It models resources with attributes, relationships, actions (“verbs”), behaviors (multi-tenancy, jobs), and facets (JSON API, GraphQL, etc.), then derives APIs, policies, specs, admin UIs, etc.

Macros, “magic”, and escape hatches

• Some fear it’s a “second language” or macro-heavy black magic.
• Defenders say the DSL is implemented via structs, with macros mostly thin wrappers; you can always drop down to plain Elixir, Ecto, or Absinthe for custom behavior.
• Critics counter that, in practice, macros + indirection produce opaque errors and force you to learn many “incantations.”

Documentation, book, and onboarding

• Earlier docs are widely described as insufficient for production; people leaned heavily on Discord and forums.
• The Ash book is repeatedly praised as the resource that makes concepts “click,” but its prominent placement on the homepage is viewed by some as a “money grab” or off‑putting for newcomers.
• Multiple commenters urge clearer high-level explanations, better landing-page copy, and more “cookbook” examples.

DX, installation, and tooling

• The curl|sh installer and randomly named example projects confuse some users; suggestions include more explicit multi-step instructions and clearer prompts to run generator tasks (Igniter) next.
• Others like the generators and note strong IDE/LSP support for the DSL is emerging.

Use cases, benefits, and limitations

• Praised for: deriving JSON/GraphQL/OpenAPI specs, powerful composable authorization policies, state machines, DAG-based workflows, admin UI generation, and removal of repetitive CRUD/context code.
• Seen as especially valuable for complex business apps and consultancies doing many similar backends.
• Critics worry it’s overkill for small/solo projects and exacerbates Elixir’s hiring/training niche.
• Comparisons are drawn to Django/Rails and model-driven development: some see Ash as “low code for engineers”; others see it as a return to the kind of “magic” they fled when adopting Elixir.