joshprice

Likewise! ElixirConfUS?

This is awesome! Can't wait to find some use cases to embed a sandboxed and safe mini Lua language in our apps.

https://hexdocs.pm/lua/Lua.html

Glad to hear you got a new project started, but let's address the ick factor.

When you define a relationship like `has_many :representatives`, Ash does’t create `representative_id` on the destination resource, we only validate that it exists and meets some criteria.

No resource ever modifies another resource, so you have to define the id on the other side using `belongs_to` which modifies it's own resource only adding the `respresentative_id` attribute with this

`belongs_to :representative, Representative`

If you need custom field names, you can override them:

`has_many :representatives, MyApp.Representative, destination_attribute: :custom_reference_id`

The docs explain more:

https://hexdocs.pm/ash/relationships.html#belongs-to

https://hexdocs.pm/ash/relationships.html#has-many

Ash was definitely inspired by Rails but takes the seed of those ideas much further. So far that it starts feeling like a flexible and extensible domain modelling language and application configuration tool. It also happens to produce a working Elixir application using the best of the Elixir ecosystem.

It's funny that you say it sounds like low-code, because we've often said it's low-code tool but for software engineers. So when you inevitably hit the wall of a proprietary no-code/low-code platform, Ash can let you extend the framework or just solve the problem by writing functions as you like.

Once you appreciate the Ash way though, be warned! It's very hard to go back...

The gap it solves is having an opinionated, UI agnostic way of building your application layer. Phoenix has very limited opinions on how to write your application, and the team has stated that "Phoenix is NOT your application". Ash basically is your app, and Phoenix is the web frontend.

https://elixirforum.com/t/what-do-they-actually-mean-when-th...

There are some fun Easter Eggs in there for the truly curious :)

That's a great suggestion, the one-liner is cute but isn't quite as readable and explanatory as your multi-line version.

Not to mention, the one-liner doesn't show off the true power of igniter -- composability and additive AST patching codegen.

Thanks!

Good catch! The issue is that we list Phoenix and Phoenix LiveView but LiveView doesn’t have its own logo AFAIk

This is exactly why honest feedback is super valuable. If we don't know where new users get stuck or confused then we can't make it better for the next person.

We'll definitely be looking at how to make it even better, because the Igniter tasks are intended to make things easier and should help explain how to get started effectively and be productive as quickly as possible.

Have you got any thoughts on how we could improve this? Perhaps a suggestion of running the generate domain or resource mix task next once the install is done?

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-...

I'm honestly really sad to hear you've had a bad time. My apologies.

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

Understand the hesitation, but this is just a convenience script to make installation a shell one-liner and totally optional.

Just click on the hard to spot "Already have an app?" link and it will show you the individual mix tasks you can run yourself.

I would argue that this is the preferred way to see what's happening and avoid running a remote shell script for the security conscious. ;)

Also the generated project name is completely random and intended to be humourous.

It's definitely worth taking another look.

The Ash DSLs get full autocomplete from your LSP and so make sure this is setup. The new Elixir LSP called Expert - https://expert-lsp.org/ is coming soon and aims to make this a much smoother process.

The documentation has been overhauled multiple times and is constantly being improved. If you encounter issues please raise an issue or a PR, knowing where users get confused is important for improving the docs for everyone.

One issue that new users often run into is that Ash is spread over multiple packages for different extensions and Hex didn't support multiple package search, which is being currently improved. So double check you're searching in the right package. Dash can help with this offline if you have it.

Tidewave (https://tidewave.ai/) MCP can help with doc search too if you are using a LLM/AI assisted editor like Cursor, Windsurf or Claude Code, etc. We also have some Ash specific announcements this week along these lines... ;)

There is definitely room for the Phoenix Form helpers to do more. Iommi looks like a really interesting approach I hadn't seen before.

For example AshAdmin (https://github.com/ash-project/ash_admin) takes these ideas further and generates a full super admin interface for you. It's a bit clunky and you should ultimately write your own admin, but it lets you focus on the important parts first.

For anyone else who hasn't seen it Iommi's motivation and docs are here:

Motivation https://kodare.net/2024/09/11/why-we-wrote-a-new-form-librar...

Iommi Forms https://docs.iommi.rocks/forms.html

Iommi Github repo https://github.com/iommirocks/iommi

Check out the docs for the Ash Igniter mix tasks, they will generate skeleton code for you:

https://hexdocs.pm/ash/Mix.Tasks.Ash.Gen.Resource.html will generate a new resource for example (and the Domain if it doesn't already exist).

Check the side bar for other generator mix tasks.

Thanks for the feedback, we'll try and make this DX clearer!

So Ruby off Rails??

Absolutely, if your customers want websites or ecommerce shops, then that's totally true.

The context here is that Alembic builds custom business applications where these problems have not typically been solved before. We want to spend most of our development time on the core business problem not rebuilding things like Content management systems or Ecommerce shopfronts.

That's really helpful feedback and there are few comments mentioning exactly this and you're right, we can definitely explain more up front on the landing page so it's more obvious.

Thanks!

AshGraphQL (https://github.com/ash-project/ash_graphql) errors are relatively customisable

https://hexdocs.pm/ash_graphql/handle-errors.html

Rails are definitely inspiration for the way Ash DSLs are used to model your business domain, but Ash takes this idea way further.

Ash models nouns and relationships like ActiveRecord does, but it also models Domains (think DDD bounded contexts) and Resources with the verbs or "actions" of your system.

It also lets you configure generated APIs and your data layer (eg Postgres) so it doesn't stop at just how an ORM may typically model your data.

Oh hey Scott! :)

"Magic" in software can be good or bad. I've tried to explain the apparent "dark magic" at the end of this article.

https://alembic.com.au/blog/essence-of-ash-framework

Would love any feedback as to whether this helps allay your fear and dread!

Spark is the DSL library that takes a DSL definition as Elixir structs and builds the DSL for you which in turn takes the written DSL and converts to a standard and simple data structure. So there are fewer macros than you might expect. Ash extensions just introspect that generated data structure with ordinary Elixir code.

The main macro in Ash core itself is the `expr` macro which enables portable declarative predicates which can be used in data layers like AshPostgres for filtering in SQL queries. If your data layer is simple like ETS or a CSV then it runs as Elixir code.

Ash models an application's verbs or operations as actions. This allows the production of events via an "Aspect Oriented" way of hooking into the action lifecycle.

Although it doesn't support a command first Event sourcing approach, AshEvents (https://github.com/ash-project/ash_events) does help produce events that could be replayed.

Torkild wrote an article about his latest updates to AshEvents here:

https://alembic.com.au/blog/ash-events-event-sourcing-made-s...

There is a post that Mike wrote that describes the thinking behind Ash's declarative approach

https://alembic.com.au/blog/declarative-programming

I just wrote a post which attempts to explain the big ideas in Ash as I see it. Would love your feedback on whether this helps answer your excellent questions

https://alembic.com.au/blog/essence-of-ash-framework

Right and unlike an ORM which only models the "nouns" and "relationships" of your business domain model, Ash also models the verbs.

This allows it to reveal the actions of your system externally via GraphQL or JSON API as well as modelling the data for your relational schema (although data layers are swappable and are not always relational).

Exactly! That's a great way to think about it in Django terms.

Unlike Django, Ash is not a web framework, it’s an *application* framework.

One way to think of it is that it’s a flexible and extensible domain modelling language that also happens to derive an Elixir application which can be called from Phoenix web UI (or something else like an API, a terminal UI or even an MCP server.

I've talked about this a few times and this is the shortest answer to this question. The first part of this talk may help explain concisely where Ash fits at a higher level.

https://youtu.be/10VBTcN8gAo?feature=shared&t=133

Ash Framework was created to solve a fundamental problem in (web) application development for business apps. When you build a new app, you want to focus on the valuable, innovative parts - what's visible above the waterline of the iceberg. However, modern web applications require an enormous amount of "below the waterline" functionality that's essential but not where you want to spend your time.

Running a consultancy and building various client projects highlights this challenge. Everyone wants to focus on the core, valuable features, but must also deal with relatively boring, commodity problems that have been solved countless times before. This often means reinventing the wheel, which clients understandably see as low-value work.

Authentication is a perfect example - most customers don't even specify login functionality as a feature. Similarly, admin interfaces are considered table stakes for modern applications. The list is extensive: admin UIs, observability, security, and more. All important, but time spent there can feel wasteful when you'd rather be innovating.

Ash's primary goal is to keep you focused on the innovative work above the waterline while minimizing time spent below it. The framework accomplishes this by modelling your domain and deriving everything else.