I've been using Elixir for over 10 years, if it was ever a "small fraction of the Rails community" it was during its formative years only. Elixir is fully its own thing. We don't even really talk about Ruby? I really do think you've got a mixed up perception on that front

Factor in that building essentially any server-side tooling without Elixir (BEAM) is a bad idea in my view, you end up with "lets just make this the way we build apps, and do it in Elixir". It's been very powerful and we're continuing to progress on it.

The concept is you model the core of your application and build it at the same time, using declarative tools, and project additions layers from this definition. The underlying data model is extendable via, well, extensions. These extend the DSL schema.

It's not conceptually a knowledge graph in the same way, but you can introspect essentially everything about your application. However, resources can be given data layers which define how they map to underlying storage, and you could use all of this information only as static information to derive additional things from, or you could just...well, use it. i.e `Ash.read(Resource)` yielding the table data. Our query engine has the same semantics they describe where you don't explicitly join etc.

```elixir MyApp.Post |> Ash.Query.filter(author.type == :admin) |> Ash.read!() ```

You can generate charts and graphs, including things like policy flow charts.

---

Ultimately I've found that modeling tools like UML that can't simultaneously actually execute that model (i.e act as the application itself) are always insufficient and/or have massive impedance mismatches once rubber meets the road. The point is to effectively reimagine this as "what if we use these modeling principles, declaratively, from the ground up".

https://ash-hq.org

> Model your domain, derive the rest

Been doing this for 5+ years.