Only half a data point: I played around with it for a private project. It works but the documentation is far from good enough for production. I was even considering getting the book, but it's not out yet. In my humble opinion, normal documentation should be enough to understand a framework, otherwise you can't expect anyone beyond hobbyist and enthusiast to pick it up. "Break out" is definitively part of the design goals, so I always felt like they put a hatch.

This is one of the earliest projects we did with Ash. It's a really big app and the customer architect was convinced that if we didn't use Ash then they'd ultimately end up building some custom version of what Ash provides.

https://alembic.com.au/case-studies/from-paper-to-precision-...

We use it in production and are really happy with it.

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.

I've got an app coming out of beta that runs web accessibility scans, which uses Elixir+Ash. Beta testers loved it, it's been very stable and I barely had to touch it over the beta period.

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.

I tried it out at the start of a new project last year. After 3 weeks, I finally threw in the towel and started from scratch in plain phoenix. By day 2 or 3 I'd surpassed what I'd managed to somehow get working, mostly by trial and error, in Ash.

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.

Hello, I have two projects in prod on ash!

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.

It's not really producing a whole separate language that I've found. There is a lot of functionality so the learning curve has been pretty steep to start. The macros are for pretty specific things but once you split out stuff like permissions, changes, etc you just use normal elixir modules. I can't think of any situation where I'd need to go outside of it and couldn't. It is built on top of all my normal elixir stuff and I've had no issue using them as normally. I'd definitely suggest reading the book first though there is a lot of unknown unknowns with it.

I've been using Ash for a few side projects and recently started using it at the day job too. We're mostly using it for new functionality, with the Ash APIs alongside our existing ones, but planning on slowly moving older things over too. It's been working well so far, and it's been easy enough to use the escape hatches for anything weird we're doing.

Getting started was a bit tricky though - definitely recommend the Ash book there. It works a lot better than the documentation as an introduction.

Echoing my comment from one of the other threads:

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.

weary (tired) -> wary (cautious / afraid)