We really would love to do this but ultimately we are constrained by how long the book would have to be to go into all of that 
But that kind of content would be great to get into once the book is out, either as blog posts or docs pages in the framework’s docs.
Yeah, totally, but still would be great to have some blog posts or any other resources who dive in Ash internals, i think would clarify a lot of things and might reduce this “hard learning curve” impression, looking forward to code contribute with Ash someday, i’m loving the book, i think it’ll make myself regret my decision to give up Ash 
I don’t want to be that guy but “sounds like a skill issue”.
You write that it “keeps you using functions like create_project”. These functions are basically just examples. If you feel strongly about it you can write a function like that in any ash domain and it would work.
At work we use DRF (Django rest framework). It’s a little similar to ash (but much worse). Two years ago the maintainers decided that it’s perfect and disabled issues and discussions on GitHub due to “social DDOSing”. However, DRF gives us so much that we need to stick with it. So any time you choose to depend on any type of software you run this risk.
I believe that particular point isn’t accurately described as a ‘skill issue.’ Rather, it reflects a difference in workflow compared to my established Phoenix practices. In Phoenix, you utilize generators to create a standardized context structure, and then you customize it by writing plain functions. Ash, in contrast, centralizes everything within resources using a DSL that permeates your core business domain. This represents a significant shift, which is why even experienced Elixir developers sometimes struggle to ‘grasp’ Ash initially. You essentially need to adapt to a new DSL and a different paradigm.
While I acknowledge that this isn’t necessarily a ‘caveat’ in the negative sense, and I agree that saying ‘Ash keeps you away from Elixir’ was perhaps an overstatement on my part, it undeniably diverges from the ‘Phoenix context workflow.’ That’s why using Ash felt weird to me initially. Thanks for give your opinion by the way mate 
You are, of course, right in the way that Ash has it’s own DSL. That is the entire point of Ash.
Phoenix contexts are largely a convention. They aren’t enforced in phoenix in anyway. You can just as easily do things in a Liveview that you would ordinarily do in a context. Phoenix doesn’t try to force you into a right way. It is very different to Rails as an example or Django Rest Framework which very, very much want you to do stuff a certain way and otherwise you are in a world of pain.
Similarly, Ash doesn’t really tell you what to do where. You can pass an Ash Resource to MyGreatBusinessDomainContext and do stuff with it. There is no magic here.
Once you have writte enough applications you realise that every application does the same stuff. Fetch some data, provide some filtering and sorting on it, run some authorization on reading and writing actions, etc. Ash gives you a fantastic DSL to do this in a declarative way. That is what it is all about. Of course I can implement this all by myself in my vanilla contexts but I will, inevitably, re-invent the wheel and simply try to do what Ash does better anyway.
Ash has a lot of features that can sometimes speed up development, but it isn’t for everyone or every team—largely because it comes with significant drawbacks that aren’t immediately obvious. For context, I’ve been programming for over a decade, I’ve used Elixir for about eight years, and I’ve been working with Ash on a daily basis for the past four months.
In my opinion, viewing Ash as just another framework is misguided. While I don’t want to get mired in the “What is a framework?” debate, a good framework provides a supportive structure without imposing rigid constraints on how you build. Phoenix illustrates this well: it suggests a broad outline but lets you shape and even deviate from that outline however you need. Ash, on the other hand, feels more like its own language—a comprehensive DSL that’s powerful but also highly opinionated. Often, it feels like a straitjacket: you don’t fully realize how it limits you until you attempt something ordinary and run into cryptic errors. It’s also unclear when and how you’re supposed to deviate from “the Ash way,” which isn’t well documented.
This dynamic reminds me of my experiences with front-end frameworks: Vue and React. I like Vue because it provides a skeleton and guidance but mostly stays out of the way—you’re still basically writing JavaScript. In contrast, React is always in your face, and straying from “the React way” can be painful. In that sense, Vue is like Phoenix, and React is like Ash.
My team recently began to “Ashify” our codebase at work. Initially, I was open-minded, especially since it was pitched as a way to reduce our tech debt by standardizing common operations, but once I built a new feature with it, I realized it drastically reduced both my productivity and my enjoyment of programming. I’m not the only team member who feels this way. The extensive “magic” also brings Rails to mind, which I used early in my career but left for Elixir. In fact, coding with Ash doesn’t really feel like writing Elixir at all, given that the DSL seems to be heavily macro-driven. For a rough (and admittedly unscientific) comparison, the Phoenix repo has only 19 defmacro statements, whereas Ash—around the same size—has 62. That’s disappointing, especially since one of Elixir’s guiding principles is to use macros sparingly:
Even though Elixir attempts its best to provide a safe environment for macros, most of the responsibility of writing clean code with macros falls on developers. Macros are harder to write than ordinary Elixir functions, and it’s considered to be bad style to use them when they’re not necessary. Write macros responsibly.
Elixir already provides mechanisms to write your everyday code in a simple and readable fashion by using its data structures and functions. Macros should only be used as a last resort. Remember that explicit is better than implicit. Clear code is better than concise code.
Or, as computer scientist David J. Wheeler put it, “All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection.”
Yeah, in my experience this is broadly one of the primary criticisms of Rails more broadly: the magic is great when you’re first starting a project because you can move at what feels like light speed, as a lot of common and generic stuff like sorting, filtering and pagination are included. Eventually though you find yourself having to actually know and think about what is going on under the hood, and having to deviate away from the “Rails way”, and complexity skyrockets and the cognitive load becomes too much.
By way of constructive criticism, Ash’s documentation could stand significant improvement. It often feels auto-generated, with crucial details added as an afterthought. Maybe I’m spoiled by Elixir and Ecto’s excellent docs, but it’s not encouraging when my teammates say, “The docs aren’t clear, but check the Ash book instead.” I’ve also sought help on the Elixir Slack’s Ash channel, only to be advised to join the Ash Discord, which itself is separate from the main Elixir Discord. This is both puzzling and somewhat emblematic of my broader point that Ash feels more like its own language. 
To address the point on support: we provide free support pretty much everywhere including in the elixir slack and here. I’ve only advised joining the discord because there are more people there (by their own choice) who may be able to help. We’ve also answered hundreds of questions here
We are gradually improving our docs (would hardly call docs an “afterthought” but there is room for significant improvement 100%).
If you’ve ever felt truly limited by Ash please bring those things up to us. It may highlight improvements that can be made, or it may highlight misconceptions on your own end that can be cleared up.
I mean, that’s better than the alternative of “the docs aren’t clear, and now I’m totally stuck.” Yes there’s room for improvement in the docs, but different people learn in different ways and perfect should never be the enemy of good. It’s a work in progress.
(The process might also be quicker if you told us where you got stuck, or contributed improvements back so everyone could benefit.)
Random thought: when you set up AshAuthentication, was it before we added the igniter installers for it? The new installers generate the actions directly into your app which makes it much easier to understand what Ash is doing, and also to see what kinds of things you might want to test.