borromakot

When I hear "next-gen" and "modern" I hear "we don't have a real value proposition except 'its not the incumbent thing'".

Imagine a scenario that a black family moved into your neighborhood and started causing a bunch of problems. There are no other black people in the neighborhood.

It should take you a picosecond to figure out which one of these is obviously racist and which isn't:

"We need to remove the black people from our neighborhood"

"We need to remove the new family from our neighborhood"

People like "well he has a good point they are causing problems" so technically the set of "black people" and "people who are currently causing problems in our neighborhood" are the same set. This is irrelevant.

"Hence" means, "therefore", as in "I didn't want to shout and shame, therefore I wrote this blog post"

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

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

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

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

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

Like flabbergasted.

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

> Model your domain, derive the rest

Been doing this for 5+ years.