Check out Freedom Formatter.
arcanemachine
hubertlepicki
No, you appear to be completely right and I was wrong. This indeed looks very nice. I apologize and stand corrected.
Looks like you did titanical work with the generation of database from the schema, but it appears you are saying I can keep using Ecto directly too if I want.
This is very cool, I will be looking closer into Ash, thank you! 
13
D4no0
I can completely agree with that!
I never used Ash, however I naturally arrived at the conclusion that such an approach is useful in a lot of cases, as it allows more flexibility between the declarative and implementation part. There were projects where I have implemented a small part of what Ash is from scratch, and I can say that it is worthwhile to go with this approach.
Nonetheless, writing implementations for DSLs can be tedious and extremely complex. Ash levels that field by providing a battery included solution for the implementation, that is usually the hard part, so you can say it’s a win-win situation as long as the framework offers the solution.
2
sodapopcan
I was waiting to see if you’d respond and was just coming back to deliver a much less coherent version of your response 
Glad you are more convinced, @hubertlepicki. I’m also a big fan of fully top down (from UI) and I was really excited about Ash. Unfortunately I wasn’t unable to convince my company to use it for their greenfield project so my Ash learning is on hold (my hobby programming time as been spent on other projects, atm).
Even though it’s two years old, there are a lot of “a-ha” moments in this video. It’s quite long (there is a part two) and these moments are a bit spread out, but I think it still does a good job of dispelling—with examples—a lot of the common misconceptions about what Ash is.
I’m only bothering to write this as this isn’t the first time I’ve seen someone say that they don’t want to use Ash and then describe Ash when trying to explain what it is they do want So coming from someone who was a previous skeptic and has zero biases (I’ve never contributed to it or even currently use it in a real project), you should really check it out if you’re a current skeptic.
3
Rich_Morin
I’d like to see better tooling for exploring and understanding both the static and dynamic structure of complex Elixir (et al) systems. People talk about how Elixir systems can have millions of processes, but generally this involves a lot of replication. So, in Rich Hickey’s terms (e.g., Simple Made Easy), it doesn’t complect things very much.
The real challenge (IMHO) is making it easier to comprehend the relationships among thousands of data structures, files, functions, process and message types, etc. Observer hints at this when it draws diagrams of supervision trees, but that is only one type of connectivity. Each instance of message transmission or process spawning has the potential to create new relationships among sets of entities (e.g., CPUs, nodes, processes).
I’ve imagined setting up a system that could harvest these relationships from static (e.g., code) files and dynamic (e.g., trace) data, then record them in (say) a graph database such as ArangoDB or Neo4j. This would make them available to generate diagrams, sets of interlinked web pages, etc. There is also the possibility of using an LLM to examine and explicate this information. And a pony…
6
jam
Same. LiveView is cool but imo the apps with the best ux are the opposite, i.e. local-first with server sync.
Currently I’m building my own solution involving Svelte, IndexedDB, and Phoenix channels. CRDTs are fascinating but I think only truly needed if doing something like collaborative document editing. This was an interesting read Architectures for Central Server Collaboration - Matthew Weidner and follow up discussion.
This sounds amazing.
4
linusdm
When I read your post, this association entered my thoughts: Kino.Process — Kino v0.19.0
Kino.Process can be used to draw traces of messages, application trees and supervision trees in Livebook. The traces overlap a bit with what you explained I guess.
2
venkatd
What I would love is something similar to Phoenix LiveView but JUST the data store itself. We use a hacked together internal implementation that sits on top of Phoenix Channels and sends diffs over to a data store on the frontend.
The boundary where the server renders the markup has not personally been a good fit for me because I work on a lot of applications with high levels of interactivity.
Offline-first seems interesting, but for many apps it could be a lot more complex than necessary. Whereas something like LiveView that syncs data (rather than html) over to an in-memory store on the frontend has similar trade-offs and complexities.
Thoughts?
1
greven
jam
would love is something similar to Phoenix LiveView but JUST the data store itself
Sounds like LiveState as mentioned above. I think the same author built LiveSignals to sync the data to your frontend.
I haven’t explored either yet but I’m also not sure I want to keep a bunch of state on the server. Would be curious to hear other’s experiences with it. For now, I’m trying to keep my dependencies to a minimum.
Offline-first seems interesting, but for many apps it could be a lot more complex than necessary.
Yeah even if it’s not “offline-first”, I think there is value in thinking “client-first” particularly for applications with lots of interactivity as you mention.
2