Ash: A Gentle Primer | Hacker News Reader

Ash: A Gentle Primer

jon.hk

102 pointszachdaniel15 comments

For those expecting something else (Almquist shell)

https://ftp.netbsd.org/pub/NetBSD/NetBSD-release-10/src/bin/...

Also known as Dash in Debian (it's satandard POSIX shell) and sh in Busybox that sadly tainted the original BSD source file with GPL2.

https://github.com/mirror/busybox/blob/master/shell/ash.c

I'm totally gonna start using "satandard" from now on.

This looks like a well-written introduction, but I’m wondering if using Ash would be a good idea.

I found an article about the philosophy of Ash. [1] The basic idea is to extract a lot of details to configuration and make the code data-driven.

This isn’t necessarily bad, but the result looks superficially like Gradle or Nix, with configuration being done using obscure scripting languages. I hope it doesn’t inherit their flaws?

To be cynical about it, “declarative syntax” is just a way to say that it acts as a config file. There is often no reasoning about config files. You just need to read what all the config parameters do, and if the documentation is inadequate, you need to read the source code of the program that ingests the config file, or perhaps do experiments. In bad cases this can be like attempting to read an interpreter or compiler to understand a programming language. It’s how you get systems that are notoriously difficult to understand.

How does Ash avoid that?

[1] https://zachdaniel.dev/incremental-declarative-design

Ultimately we avoid that with a few specific things:

1. As sane config as possible.

2. ability to hook into functional processes and see what's going on

3. Layered escape hatches. You can add functional hooks to actions, or you can use a manual action to take over the data layer interaction, or you can write a "generic action" which gives you even more control. The escape hatches are designed to allow as much customization without sacrificing capability as possible.

4. Ash isn't its own language/environment. It's just an Elixir library. If doing something with Ash is proving difficult for whatever reason, you can opt not to use it for that, and then you're back in Elixir-land in full control. Ash doesn't attempt to "own" the things you use it with (in fact we take extra care to be as compatible with other tools as we can. For example, each Ash resource is also an Ecto schema. In this way, Ash can handle the 90+% of your application that is typically table-stakes, and you can handle the rest.

Also, I liken declarative programming to sushi. There are a lot of people who don't like sushi, because they've only had bad sushi :)

Thanks for explaining!

Another approach that I think works well is exemplified by ‘make -n’ where it prints a script for what it would do in a particular situation. Make’s rules-based syntax has its advantages, but imperative scripts are also pretty easy to understand, so it’s nice to see a conversion from one to another. (To go deeper, though, you need to understand what the commands do.)

I haven’t used it, but I believe the Cue language can generate JSON output, which would be another example of translating from a sophisticated config language to a simpler, more verbose one. (Though, again, you need to understand the code that ingests the configuration to go any deeper.)

I have been writing Elixir full time since 2018, and I quite like Phoenix, warts and all.

Can a willing reader pitch Ash Framework in a few lines for me please? What is its killer feature vs Phoenix? Also, is it compatible, or does it have an alternative to LiveView?

Ash isn’t an alternative to Phoenix. It’s an alternative to Ecto. It’s a data layer that uses Ecto under the hood.

If you read the first few paragraphs of the linked tutorial, I think you’ll have a pretty decent understanding of what it does.

You can use Ash with Phoenix and Liveview.

I really wish the Ash website made this more immediately clear; the initial description makes it sound like Ash has a broader scope than it actually does (as far as I can tell).

We tried to make it a bit clearer recently with the section on "Compatibility". "Works great with Phoenix, Ecto and all the other first rate tools in the Elixir ecosystem."But you aren't the first person to say this. It's complex because we do build your APIs for you, and it's not a requirement to use Phoenix to make this work. But Ash also can (and usually does) act as something you use alongside Phoenix. It makes it difficult to message :(

Well, today I learned, thanks.

Hi, the tutorial writer here. The first few paragraphs in the tut would give you a sense of what Ash does, but thank you for the comment that its role in comparison with Phoenix should be spelt out at some point. Ash helps provide a thoughtful underpinning to structure your data, and Phoenix / LiveView presents it to the world. If you are a poetry person:

Phoenix rise from Ash.

It doesnt replace phoenix. Think of it as ecto schemas but with superpowers. Instead of "just" getting changesets etc from a schema you get json api, admin, calcuations etc.

Really curious about experiences of people that use or used Ash in production. Are there any gotchas or is it really easy to work with?

It's an elixir framework, not the the shell in Alpine Linux ...

Reply on news.ycombinator.com