borromakot

it is not just you

holy shit this is awesome.

pretty cool, any plans on making it OSS some day or sharing more about your process? The Ash community would love that I'm sure.

A new Ash Framework extension called Ash TypeScript makes it easy to expose actions to a frontend by generating a typed client library and RPC controllers.

This video walks through a project, with source code that can be found on GitHub: https://github.com/ChristianAlexander/ash_typescript_demo

Make sure to tell the team about it, and ask questions about it. Sometimes it's hard to tell the difference between magic and a misunderstanding

If I sounded snarky that wasn't my intention. At the end of the day though it doesn't feel like you read the article which was clearly in a different context than the one in which you responded. FWIW I didn't expect this small article speaking to a small audience (Elixir devs) to make the rounds on hacker news.

I agree on the importance of defining terms, and I think the important thing here is that "process" in Joe's parlance is not an OS level process, it is one of a fleet of processes running inside the BEAM VM. And the "system" in this case is the supervisory system around it, which itself consists of individual processes.

I'm critiquing a common misunderstanding of the phrase "Let it crash", whereby effectively no local error handling is performed. This leads to worse user experiences and worse outcomes in general. I understand that you're offering critique, but it again sounds like you're critiquing a reductive element (the headline itself).

Then I don't think you understand how the phrase is used in Elixir/Erlang. The phrase is about letting processes crash.

Blog guy here: I do, in fact, know it better than a lot of other Elixir devs.

Author: I'm literally explaining not to interpret the tag line at face value.

Errors during initialization of a BEAM language application will crash the entire program, and you can decide to exit/crash a program if you get into some unrecoverable state. The important thing is the design of individual crashable/recoverable units.

Have you used `usage_rules` yet?

Really awesome release, stoked with the direction things are going.

That is like 0.5% of what Ash helps with :)

In what way were the not "secure"? Showing you their schema is literally what they are supposed to do.

I mean, MCP servers have tons of sec vulnerabilities but "showing you their schema" and "having bugs" aren't vulns.

There are two terms.

* call - to send and await a reply * cast - to send and not await a reply

Simultaneously bullish on LLMs and insanely confused as to why anyone would literally ever use something like a Supabase MCP unless there is some kind of "dev sandbox" credentials that only get access to dev/staging data.

And I'm so confused at why anyone seems to phrase prompt engineering as any kind of mitigation at all.

Like flabbergasted.

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.

This has been a wildly useful tool for me and my team.

High information density is good for LLMs. https://ash-hq.org benefits from this, but hurts due to being fairly new. https://hexdocs.pm/usage_rules is helping.

You are probably right

https://github.com/burrito-elixir/burrito

Well-designed Erlang systems can fail gracefully and self-heal locally...but they’re only as fault-tolerant as their distributed architecture and ops discipline allows

Correct.

you went for an ad hominem

Not my intention. I asked a simple question, and you answered a question with a question, effectively gish galloping me with "but there are ways it can crash" except nobody said there wasn't. It stopped feeling like a technical debate at that point.

FWIW, I didn't make the original comment you replied to, I just pointed out that this statement:

"Practically never crash" ignores software bugs, resource exhaustion, or bad architecture

felt like a surface response to the OPs sentiment of localized failures not tanking an entire software system.

What I mean is that, you can write CLIs in Elixir. I have. You can write games in Elixir (others have, I haven't). They come with pros & cons. The Elixir community advances on many of those fronts regularly. I could write a web application in C, but I wouldn't.

1. Yes 2. You didn't answer my question? Your answer ""Practically never crash" ignores software bugs, resource exhaustion, or bad architecture" indicates I think ignorance of actually deploying BEAM applications, and instead just making statements based on things you've heard. Isolating failures in software systems is not a bad thing. The developer can choose the boundaries between the elements of their system up to and including "stopping the entire application if things go wrong".

It having strengths and weaknesses doesn't make it not general purpose language.

Have you written/deployed Elixir before?

Elixir has been quite easy to set up, configure and deploy, at least for the last 5-6 years. I can't speak for Erlang though.