Hacker News new | past | comments | ask | show | jobs | submit | joshprice's comments login

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


Thanks Josh, hope to see you soon, its been a while


Likewise! ElixirConfUS?


Probably not, you should come to Code BEAM NYC, although a bit of a trek for you.

I will be trying to travel more in 2026


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


Thank you for taking the time to answer so kindly


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


Nice, thanks for the writeup! A small heads up, Phoenix is listed twice in the tech stack section.


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


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.


Ahhhh, okay! Looks like I’ve got a bad roll of a dice then. (The `uber_for` is actually hilarious :-)

Maybe move the script to something like ash-hq.org/new?project_name={generated}, so that it’s easier to guess what’s going on? Or break it up into steps, like:

    # Install prerequisites (Elixir and `igniter_new`):
    curl -fsSo 'https://ash-hq.org/install?with=phoenix' | sh

    # Create a new app:
    mix igniter.new {{ generated }} --yes-to-deps --yes --install ""
    cd {{ generated }}

    # Install Ash:
    mix igniter.install ...
(This could also let you eliminate that “Already have an app?” button-link – the users can just skip the steps they’ve already done.)


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!


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


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!


Don't get me wrong. I really support these kind of frameworks. I'm a fan of Rails, Phoenix, Django and Laravel. But if me, as a strong supporter, can't get it right; how can someone who's skeptical?


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?



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


This has been good to read and the pictures were very helpful, thanks.


Just wanna chime in and say expr is the bomb


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


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: