zachdaniel

I think its also important for people to realize that

1. its opt-in, if you don't like it don't use it :)

2. we don't do magic migrations. We generate a regular ecto migration from your resource changes. So you can use it as a starting point and hand edit it (and often you should or even must as we can't do things like generating data migrations).

3. you don't have to map your resources one-to-one with tables. We support multiple resources being sourced from the same table, and turning on and off migration generation per resource. It's very common to have an Ash resource backed by a postgres view, or two ash resources backed by the same table. The migration generator merges resource definitions together to create "the strictest table definition that supports both resources". You can also remap field names. So at the end of the day, you can have your cake and eat it too on that front.

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 :(

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 :)

Okay, fixed :)

Yep, because I pushed a different change and accidentally removed the word Elixir again. Pretty stupid of me, it’s been a hectic day. We’re putting it back as we speak.

Not at all! Just an oversight :)

Thank you

Thanks for the feedback! Its pretty difficult to find someone with no context on what we're building at all and say "hey does this tell you what this thing does/what info is missing", so this is very useful.

We share a lot in common with those design principles, yes. Ultimately though I don't believe in modeling as a sort of "pure" thing that you can do in advance of coding. Our tools are aimed at essentially doing both at the same time, finding the middle ground between your domain model and reality.

It now says "Elixir" right on the tin :)

Our recent changes to the website aimed at trimming it down were clearly overzealous.

We used to have tons of information and I spent a bunch of time removing it all trying to simplify. I very clearly removed too much . But, it’s definitely not GPT generated.

So, something that is very clearly true is that was need to make the website better :). We aren’t being vague on purpose! Most people who go to our website have gone with an idea of what Ash is already having seen a talk from me or talked to someone about it.

When they don't you just write them yourself. All we do is generate migration files to provide a good starting point. Its a convenience tool.

To clarify: it's the same reason that I like plug.

For the same reasons that the author dislikes Tesla, I prefer it :D

Very kind of you to say! Getting it out of Alpha has definitely taken longer than I initially expected, probably something any other OS maintainer would have told me, but we're getting closer! Mostly need to make a few big documentation/testing pushes and then it should be ready. I want to redo the website and create a "book style" documentation site that has all the extension documentations in one place.

Hey there! I'm the author of Ash Framework, happy to answer any questions you have. A few people have deployed to production with Ash and are seeing good results, but it is definitely at the "sharp edges" phase, where its great if you're okay with hanging out in our discord and troubleshooting, and even better if you're the kind of person who can dive in and PR whatever change is needed.

Feel free to join the discord as well if you just want to follow along: https://discord.gg/WZCECgMe

https://elixir-lang.org/cases.html here you go

This highlights something interesting for me: I've literally never heard anyone "arguing" that they should have the title of "software engineer" or "programmer" or "software developer". I don't know the history of it, and it could easily just be something that I haven't personally witnessed. Ultimately I fall into the camp of someone who would do fine getting quizzed on the computer science stuff, but at the same time it is ultimately about adding value (at least, when we're talking about someone paying you to work for them).

There aren't two camps: "glue software engineers" and "computer scientists". There is a spectrum of people with varying abilities in a wide array of sub-fields.

Ultimately it seems strangely exclusionary to draw lines in the sand like this. Everyone who learns how to program doesn't need to A.) be god's gift to the science of computing and B.) have the same level of understanding/fluency in what they're doing.

It's like saying the only way to teach any amount of a language is to require 6 months of total immersion. There is value in someone taking on year of a language and learning a few phrases, and moving on. Ultimately, people have practical and immediate concerns, like getting paid and putting food on the table. We aren't all programming for the same reasons, and sometimes getting the job done is all people have time or even the inclination to do. And we shouldn't judge them for that.

I'm not suggesting that he is entirely wrong, but reading things that sound like proselytizing just make me sad. There is so much room to educate and come to mutual understandings. Some people might think they've found a better route or a deeper understanding, but treating the rest like idiots is the best way to make sure they never get your message.

No need to be rude.