Oi Brasil, saudades! 🇧🇷 Criei um novo canal no YouTube em PT-BR para falar principalmente sobre Engenharia de Software assistida por IA youtu.be/MePgWwtpyDY?si=TMVy…

Very exciting feature coming to LiveView: subscribe to a PubSub topic from any LiveView (or LiveComponent!!!) and LiveView will automatically manage the subscription for you. Simply: subscribe(socket, "user.updates", &handle_user_updates/2) PR: github.com/phoenixframework/…

People have been dramatically overengineering AI for a while now. Just talk to the agent for god's sake! It is 1000x smarter than you think, no need to have bajillions of MCPs and skills installed

That’s where I want to see more AI

What frustrates me the most is the lack of curiosity. People saw the numbers they wanted to see and ran with the story. They didn’t ask about the process. They didn’t question the results. They didn’t explore the code. They didn’t look at the history. You could have even asked a coding agent to do an initial investigation. There has never been a better time to be curious, dig deeper, learn... but this is what we’ve got now. Oh well.

Just so we are all on the same page: * The Rust version has hundreds of commits, with multiple optimizations rounds, over several days. The others have 1 or 2 commits from an initial agentic rewrite * Based on the available documentation, different things were asked from each attempt. The agents.md from Go mentions the Rust version was the canonical example. The Elixir one mentions it was the Rails one * While we don’t have the full prompts, it seems they were vague, allowing the agents to make non-language architectural decisions that impact results (such as how closely it should replicate Rails’ drawbacks) It is actually amazing how quickly we can have full-blown rewrites up and running. But if we want to take conclusions from the data presented, it is important to understand the process behind it.

> If the agents can't write good Elixir without good steering Nah, that's not my point. Within "Rewrite this in Elixir", there are a bunch of non-Elixir decisions that will impact the results. Should you preserve session compatibility? Should you preserve Redis messages and payloads? If you didn't give the answer, it made the choice for you, and that will change the results. For example, the agent chose Redis compability and even documented so in the README. This is an architectural decision completely unrelated from its ability to write Elixir code but it will make it so Elixir now has to talk to an additional service, while Go and Rust doesn't have to. > Same as what was used for Go, Laravel, Rust, etc. If that's the case, why was Go ported from Rust but the Elixir one from Rails (according to their AGENTS.md)? Anyway, someone already wrote a pull request here: github.com/zachdaniel/once-c… - you probably want to look at the load testing benchmarks cause the Rust one seems to be dropping messages.

Do you have the prompts or threads publicly available? The agent clearly chose to follow Rails compatibilty more closely in the Elixir version. So a few of Rails limitations got ported to the Elixir one. Here is an example from the README itself: > Elixir retains Redis and Resque-compatible jobs, while Rust uses integrated queues and a different frontend/server implementation. The agent knows, it just chose to prioritize something else, which will always happen if you are not steering. I am certain coding agents can spot those issues and bring the numbers up for both Elixir and Go with no troubles whatsoever (although I don't expect them to beat Rust).

Meanwhile web dev influencers: "I built this game with Opus 5.5". BRO, I'M BUILDING WEB APPS, NOT A MINECRAFT CLONE FOR GOD'S SAKE

At this point the only acceptable tech stack IMO is Elixir for web and Rust for everything else. Give me 1 good reason to still use a JS framework (besides extremely simple marketing/portfolio websites)

we got a lot from @elixirlang, so it was our duty to go give something back to it teams will soon be able to collect data from their builds and test runs, and lean on agents to optimize their build graphs and test suites

An older Elixir compiler accepted this Phoenix app, and its tests passed. Elixir 1.20 found an invalid public function path. We used a coding agent to trace and fix it, then checked the tests and running app youtu.be/PR7owEhL5KU?si=pwkf…

Never thought I would be rooting for a fullstack Rust framework, but here we are in the age of agents!

one shot Claude Opus 5.5, xHigh reasoning prompt: make a dynamic 15 second motion graphics video that shows what an incredible tool tidewave is

Google is always 6 months behind

Got bit by the rust virus github.com/danielbergholz/ru…

Here is a nice pun to close the week: Rust is a system programming language, Elixir is a *systems* programming language.

If we're not going to write or read the code anyway, use a technology that scales vertically and horizontally with as few moving parts as possible, like Phoenix and Elixir. Because when you have no clue what is happening, managing Phoenix+DB will be easier than App+DB+AuthService+Functions+Redis+Whatever

Not every project has a page to inspect. Tidewave IDE can now open a local directory, bringing its coding agent, terminal, Code Review, and Git workflow to libraries, CLI tools, scripts, docs, and other non-web projects youtu.be/GjyTztkGpOU?si=x_EY…

If coding agents will write most of our code, what happens with our communities and sense of ergonomics? How does it impact our compilers and tools?

What is preventing you from moving to Elixir?