We have been using Ash at work for the past nine months. Our experience has been brutal. Learning curve is absurdly steep. Macros everywhere means you have to trawl through documentation to find information about the exact thing you're trying to do, and often cannot. Every time you step out of the well-trodden path you're punished with cryptic errors, for which there's nearly nothing on the web, and AI tools are clueless about. So your only option is to post about it in the Ash discord (which is for some reason not part of the official Elixir discord) and hope that someone responds before you lose your mind.
The only thing it has done for us is that our data layer has started to look somewhat standardized. This may be a reasonable benefit for larger teams that don't have any code quality or architecture discipline. For small teams though, and especially for solo projects, I wouldn't recommend it. Your productivity will suffer.
Quite a few users have commented that the free support in Discord is incredibly fast and comprehensive. Zach responds unreasonably quickly and often you've run into a bug or unclear documentation that is fixed virtually instantly.
Like Zach mentioned, please help us understand where your challenges are and we'll do our best to help out. We can only improve things for everyone if we know where to focus our attention.
At the risk of being called a shill, if you need more reliable paid support then please reach out, we have a service for this which teams find really valuable. https://ash.alembic.com.au/ash-premium-support
Maybe it's just me, but I found the Ash (and ecosystem) codebase a lot more approachable than something like Rails.
The first few weeks on the project were tough, and the documentation challenges are certainly there, but they get better day by day.
After getting comfortable and accepting the "Ash" way, I've found my productivity to skyrocket when using Ash to build an Absinthe GraphQL api. Previously I'd have to build the context layer, then the resolvers, etc.
Now with Ash, I write my action, declare my query/mutation/subscription and get all the rest for free. I can't see myself going back to writing Elixir apps without Ash.
Ash itself is fantastic so far. I haven’t worked with anything so productive before. Loving it.
Also, the book is out now.
I know the Ash team is aware of the documentation challenge, and they are working on it. I feel like the book is an answer to that, and hopefully a lot of the greatness of the book is able to make its way back to the docs.
https://alembic.com.au/case-studies/from-paper-to-precision-...
For me, one of the biggest value points of Ash lies in removing the boilerplate without locking you in.
The devs of Ash cleverly use Elixir itself and other big names of the Elixir eco system. By doing that, they have created a framework that helps you moving more quickly as you don't have to write the same code over and over again (i.e. remove boilerplate) while still giving you the flexibility to escape if something out of the box doesn't fit right away (that's because of how Elixir works and how they just re-use the other big names, e.g. Ecto, Absinthe,...).
I've tried to write about all of this here if you are interested in reading more:
https://www.lukasender.at/ash-the-hidden-champion-of-low-cod...
In the end, it's hard to only write and read about this. You can only "feel" how things change when you actually work with it.
The learning curve is a little step at first, though (in my opinion). But the docs got a lot better over time.
All in all, I'm still happy with how things turned out and would use it again for future projects.
This app has a lot of complex headless browser flows that rely a lot on Ash.StateMachine, and Ash has only gotten better the deeper I've gotten into it. The app gets more simple and stable the more I integrate with Ash.
The declarative "data-oriented programming" paradigm took some getting used to (I come from PHP) but it makes so much sense and makes it easy to plug Ash resources into any other use case. Deriving a JSON api is an easy example.
In another app I'm using Ash.Reactor to model agentic AI workflows (it's just RAG but with extra steps). Reactor was originally intended as a saga orchestrator that models workflows as a DAG. DAG is the perfect abstraction for this use case and it works ridiculously well.
First of all, its not "macro based", as that implies dark magic and sacrificed goats. The spark dsl underlying all this is just structs all the way down in a nested manner. Just like you would see if you look under the covers of a Absinthe Blueprint produced by that dsl.
The dsl is declarative and allows to express a lot of stuff with less code, but I would say that saying its "macro based" is a bit misleading, although "technically correct". You could achieve the same by just having functions returning structs.
I have replaced a biiiiig nestjs app that exposed graphql with an ash app exposing graphql, and the boilerplate ratio for resolvers etc is bordering on 1:999. Like literally, across a 90 table large application I have maybe 600 lines of "specifically graphql related code" (5-10 lines of code to expose select actions as mutations and queries per resource). As opposed to the nestjs codebase that was using an annotation driven approach and had a gazillion lines of glue code for resolvers and data loading.
Also the authorization logic through the policies is so extremely composable and easy to do when combined with matching on resources it is fantastic. Each resource "owns" its own authorization, so there is no song and dance about figuring out acl from the entry point and then downwards a tree. You just let the resolver resolve its way down the graphql tree or just feed a long ass loader path into Ash.load and each resource is responsible to implement its own policies and you don't have to worry about accidentally leaking data because you access the data from a new entry path that was not locked down because you added a new resolver.
I kept reimplementing the same boring boiler plate every damn time I started a new project and that pain is almost 100% gone.
It is a harsh learning curve for sure, because the one downside of Ash is that you have to do it the "ash way" for stuff to compose as beautifully as it does. Once you really get into the groove making "expression calculations" (basically projections that reach into other resources or columns to make some kind of computed data, but is done in the database layer since you expose it as an expression) that you can compose and make depend on eachother etc it becomes so incredibly fast to make new functionality.
You think about one and one thing and let the framework take care of how to compose the loading and usage of what you make. A much simpler model than "making it yourself" in ecto which I have been doing for 10 years prior.
I am 100% on board with the vision, but the learning curve is absolutely brutal, and at least at the time the documentation was simply not anywhere close to where it needed to be. Something this different needs a truly giant "cookbook" to show, you know, how to use the damn thing. That was lacking and there was nothing to learn from online besides the most basic toy applications. Also, it was, at least at the time, slow as hell. All those damn macros.
Plus - elixir is already niche. Ash is a niche within a niche. I need to be able to hire people who can get up to speed in days, not weeks or months. There's a chicken and egg problem with something this ambitious - no-one uses it because no-one uses it. I hope it breaks out of this dilemma but professionally I can't bet the company that it does.
As I said I really like the idea. Anyone who has maintained an OpenAPI app will jump for joy with documentation and tests moving automatically and in lockstep with the core domain logic. But for me, at the time, it was too early, too risky and too obscure. I do wish it well though - I love these kind of moonshots and I look forward to trying it again as soon as I can.
Getting started was a bit tricky though - definitely recommend the Ash book there. It works a lot better than the documentation as an introduction.