Ash Weekly: Issue #17
Ash AI Launched, ElixirConf EU Wrapped, thoughts on the Contributors Summit & Office Hours Livestream tomorrow.
Ash Weekly!
Welcome to Ash Weekly — your quick, informal digest of what’s new and notable in the world of Ash Framework. Got something cool? Drop it in the #showcase channel on Discord!
Shameless Plugs
Check out Ash Premium Support from Alembic.
Sponsor me if you like what I do.
Ash AI Launch
Ash AI is live! Check out the announcement on Alembic’s blog! It's packed with features, from MCP servers to structured outputs. Give it a whirl!
ElixirConf EU Wrapped
This conference was really something. I’ve felt momentum from the Elixir community for years now, but this year felt like an avalanche. Not only were there tons of interesting projects, useful tools and amazing ideas in the talks themselves, but we also had the Elixir Contributors Summit afterwards. I really wasn’t sure what to expect, but by the end of the day we had so much actionable and useful information and were able to hear so many unique perspectives. Most importantly, we were able to do some level-setting and mindshare that I think will have tangible long term impacts for the Elixir ecosystem.
If that wasn’t enough, we also had an “Ignite Nerves” meetup before the conf with a focus on improving the nerves installation process using igniter. It felt like we made a lot of good progress there, and also a whole slew of improvements made it out of that, like automatically generating tests for tasks, smarter behavior around config file creation, and a `mix igniter.init_library` task to set up a library for usage with igniter for the first time. plus a few bug fixes 😅.
The Talks
I’m going to be focusing on the news, as there were a lot of announcements.
Code generators are dead, long live code generators - Chris McCord
Chris McCord announced phoenix.new, a product he’s built for fly.io which is an entire IDE, cloud environment, and bespoke LLM code assistant that speaks Elixir & Phoenix very well. It was pretty amazing to see it produce a deployed, playable Tron themed Tetris game, and I’m really pleased to see an AI product in which Elixir not only shines it is the main character.
In my discussions with others, it became clear that phoenix.new was *highly* controversial in its reception (as in, lots of people were very excited by it, and lots of people were very much not excited about it). This is a really nuanced conversation that I think deserves to be talked through. I’ve heard a lot of “putting people in buckets” that I think we really need to be careful of, and I’d like to try and blur the lines a bit in a way that might help avoid some kind of schism when it comes to AI/LLM tooling. The most notable generalizations I’m picking up go something like this:
People who don’t believe that AI tools are a net good and/or don’t believe that we should be using them feel this way because they are afraid for their jobs.
People who believe that AI is the future of software development are just trying to push slop and don’t care about building quality software.
While there are definitely some people on the far ends of these spectrums, the reality of it really isn’t so clear. Despite what anyone says, AI and LLMs often produce very low quality code or fully broken code. Like all the time. There are things you can do that will make it do better. Those things are constantly changing, however, and are not standardized in any way shape or form. Even when they are, sometimes things just go off the rails. I totally understand the reticence folks have to adopt and/or support this technology. For them, I’d encourage them to just keep having some small brush-ups with the tech, trying to use it in good faith, to find where it is and isn’t useful. Doing it long enough you’ll build up some muscle memory for “AI would probably save me some time here”, and you’re in a good position to leverage new AI tech if/when the models improve in the future. It’s not fair to say that these people are (universally) just “scared for their jobs”. In many cases, I think they are primarily concerned with how much *harder* their jobs might be come if people use this stuff irresponsibly (which they will).
For those that say that the AI proponents are just making “AI slop”, I think we need to give at a minimum the people in our community the benefit of the doubt. phoenix.new is a great example. They didn’t say “alright well let’s lean hard into typescript because thats what the LLMs know best”. Instead, they are starting with “how do we make this stuff shine with Elixir, because that is the best language for this task”. Think about it this way: if AI never “gets better” or never manages to meet the lofty goals that AI proponents say it will, then what’s the harm here? It’s a great prototype machine. At worst it’s a toy. But if AI continues to be a revolutionary force in tech, don’t you want Elixir to be represented in that revolution?! I certainly do.
For this I’m really pleased with the work they are doing at fly. I don’t mind if AI ends up being a diversion. I don’t think it will, but I’d rather we all waste a few cycles as opposed to getting left in the dust. The main thing that Elixir leadership needs to do IMO is make sure that we’re lifting up the whole community when it comes to AI. There are some discussions happening, and tools like Tidewave that make a huge difference here.
I’ve gotten early access to phoenix.new, and it is very impressive tech. My only complaint is that it is clearly very fine tuned to writing “right down the middle” Elixir & Phoenix code. It was a bit like pulling teeth to get it to use Ash (I never really got it to write what I’d want it to write). For me, the standards I have on how I build my software don’t change just because it can be done faster with AI. That doesn’t make this tech unimpressive, and I’ve had multiple conversations with Chris about what can be done to improve this situation. Good stuff coming on that front soon!
I’ll continue to experiment here in this space to find ways to let Ash users leverage all these amazing AI tools without compromising the way we prefer to build our applications. It is important to note that I don’t think this is some kind of “aesthetic” concern. I think Ash is one of the primary mechanisms by which we avoid the “instant legacy code” that you can get from AI code generation.
Introducing Phoenix.Sync - James Arthur
Phoenix.Sync is really exciting tech that aims to essentially create an entirely new kind of realtime stack, backed by Elixir and Postgres. The talk was very interesting and educational. The demo at the end had a tech issue that was certainly unrelated to Phoenix.Sync itself. James did a good job of keeping the momentum going (the entire room was singing at one point) so kudos to him for not letting the demo gods ruin his mojo.
As for the tech, it is quite exciting! I had a few hours to dive in and I’m looking to (big surprise) build a compatibility layer and declarative wrapper around it for Ash Framework, so that users can “slap some sync on it” and get cool real time features for their applications! I’m actually surprisingly close to an MVP on this front, and it may actually turn into something I didn’t really expect at first. As part of what I’m building, I’m doing client code generation, including zod schemas representing the data structures being synchronized. This basically means that what comes out of this is an idiomatic React stack that has to do very little to have live updating client side data, and it may act as the first in a suite of react-centric tools we build around Ash.
If we can settle on some (light) conventions for what the React code structure looks like around an Ash + Phoenix application, then installing `AshGraphql` could set users up with GraphQL codegen automatically, just like installing `Ash.Sync` will set users up with codegen for their live reloading code. I love LiveView, but I think Elixir is in dire need of more idiomatic React front end solutions.
As soon as we have a prototype worth playing with, I’ll let you all know. You can play with Phoenix.Sync right now if you like of course though.
The AtomVM and New Horizons for Elixir
Elixir on micro controllers has dovetailed into Elixir on the browser, via the new Popcorn project 🤯. New frontiers for Elixir and the BEAM folks! They are still working on it, but they already showed some really fun examples of what could be done. One such example that was punchy was that you can just click “run” on any code block in ex_doc (Hypothetically, they only did the demo for one simple block of code)! I really hope that they push forward with this project. I won’t do the technicals of it justice, so I’ll defer to them, but this is just amazing work by Software Mansion and team! The code is here and some examples can be found here.
Hologram: Building Rich UIs with Elixir Running in the Browser
The website will do a better job of explaining it than I would in a paragraph, so go check it out. Hologram is a really ambitious project, and it really takes the whole “never write javascript again” concept and cranks it to 11. Your client code and server code is all conveniently defined in one place, and the framework itself seems like a lot of fun to work with. Like any ambitious play, the question is what happens when the rubber meets the road and you need to do something crazy that no one ever thought of. This isn’t a criticism, I get this question all the time about Ash! I think what would be great to see are some demo apps that do off-the-wall things (and maybe one that just shows what some bog-standard simple web stuff looks like) to highlight what Hologram is capable of. Had a chance to talk some big ideas with Bart over drinks at the conference, he is a smart guy and I get the sense that he can pull this off 😎. If you’ve tried Hologram, please let me know your thoughts!
Ash Office Hours Livestream Tomorrow
Every month we do a monthly Ash Office Hours, to talk about what the core team is working on and answer questions from the community. We’d love for you all to join us!
Releases
Ash: 3.5.10-3.5.11
Added `Ash.data_layer_query/2`. This can allow for a special kind of escape hatch, where we provide the Ecto query with all rules applied like authorization, and all expression calculations selected into the query. You can then do with that query whatever you wish. YMMV.
Added a `:time_usec` builtin type
Support a `limit` option on `has_many` relationships
AshAi: 0.1.1-0.1.2
Make the generated chat look better.
Make permissions checks less eager to reject (incorrect option was hiding tools)
Igniter: 0.5.52
Added `igniter.init_library`, which sets up your package with an installer and a proper igniter dependency
Igniter now removes itself after installation, if it wasn’t there when you invoked the command.
Add a `:target` to `move_to_def`, which allows moving to `:inside` the function definition, `:before` the definition factoring attributes like `@doc`, or `:at` the function head itself.
Generate a test for tasks generated with `igniter.gen.task`
Spark: 2.2.56-2.2.57
Make compiled modules smaller via an internal optimization
AshGraphql: 1.7.10-1.7.11
Add `args` option to mutations, indicating inputs that should not be nested in the `input` object, and should be top-level
Add `meta` option, for adding custom resolution context
AshJsonApi: 1.4.31
Increase consistency around route & query params in the generated OpenApi schema (no duplicates, properly include descriptions & types in route params)
AshAuthentication: 4.8.3-4.8.7
Provide `action_input.context` to the send_opts in senders as `:context`
Provide a default accept phase form for non-phoenix applications
Provide an explicit name to the api key strategy when installed
The `strategy_module` field is no longer required for custom strategies.
AshPhoenix: 2.3.1
Document `:params` option for `for_action`
Rework `gen.live` to support Phoenix 1.8 expectations
support `AshPhoenix.Form` in the error subject for inertia errors