Simon Willison's Weblog: erlang

Phoenix.new is Fly's entry into the prompt-driven app development space

2025-06-23T18:42:02+00:00

Here's a fascinating new entrant into the AI-assisted-programming / coding-agents space by Fly.io, introduced on their blog in Phoenix.new – The Remote AI Runtime for Phoenix: describe an app in a prompt, get a full Phoenix application, backed by SQLite and running on Fly's hosting platform. The official Phoenix.new YouTube launch video is a good way to get a sense for what this does.

Background on Phoenix and Elixir and Fly

First, some background. Phoenix is an open source web framework for Elixir, the Ruby-like language that compiles to Erlang's BEAM bytecode and runs on top of the highly concurrent Erlang runtime. The signature feature of the framework is Phoenix LiveView, a toolkit for building realtime interfaces through streaming diffs to server-side HTML over a WebSocket connection.

Phoenix was created by Chris McCord 11 years ago, and Chris joined Fly nearly four years ago. Phoenix.new is his latest project.

Phoenix LiveView is a really great fit for Fly's geographically distributed application serving infrastructure. Fly co-founder Kurt Mackey wrote about that in April 2021, before they had hired Chris, describing how LiveView benefits from low latency by "moving app processes close to users" - something Fly has been designed to help with from the start.

There's one major challenge though: Elixir is still a niche programming language, which means the number of people out there who are ready to spin up a new Phoenix app has always been artificially limited.

Fly's solution? Get LLMs to shave that learning curve down to almost nothing.

Prompt-driven application development with Phoenix.new

Phoenix.new is a prompt-driven application development platform. You describe what you want to build, then watch as an LLM-powered coding agent writes, tests and iterates on code to help achieve that goal. It's in the same broad category as Lovable, v0.dev and and Val Town's Townie.

One of the most important problems to solve with coding agents is to give them a robust sandbox where they can run code without breaking things outside of that space. Fly, at their heart, are a sandboxing company - their Fly Machines product makes it trivial to spin up a new sandboxed VM in just a few seconds. I'm building Datasette Cloud on Fly for exactly that reason.

I tried out Phoenix.new with the following starter prompt:

A notebook application. Notes are rich text, using a nice visual markdown editors. The first line of a note becomes the title. Notes have a URL that is a 6 character random text string - thise can be used to link notes to each other by dropping in an @ sign and that text string. A hash and then text becomes a tag, clicking a tag goes to a page with that tag on. Notes are all in SQLite FTS so they can be searched with a search tool.

Watching it work was fascinating. It provides a full IDE-style environment in the browser, running a dedicated container and with a forwarded port to allow you to interact with the running application while it is being built.

It spun up a plan.md, planned out the approach and started working through the code. Most interestingly, it constantly tested the application it was building using a testing tool that looked similar to my own shot-scraper. Here's an example of the output from that:

I can see the issue! The page is still showing the "Welcome to your Notebook" message instead of the form. Let me wait a moment for the JavaScript to execute and then check if the form appeared.

$ web http://localhost:4000 --js "setTimeout(() => { document.querySelector('button[phx-click=\"start_creating\"]').click(); }, 500); setTimeout(() => { console.log('Form visible?', !!document.querySelector('textarea')); console.log('Creating note state:', document.body.innerHTML.includes('Create New Note')); }, 2000);"

I'm used to coding agents that write and execute their own tests, but this is the most impressive example I've seen of a coding agent that actively interacts with and tests the live application while it is iterating on the code.

Most interestingly of all, since LiveView is a realtime framework, I could interact directly with the application at the same time as the machine was writing and testing it, seeing any changes it made instantly in my browser!

How did it do? It got there in the end, but with hindsight my initial prompt was a little too complex: I had to rescue it after it got stuck in an error loop trying to implement SQLite full-text search. Just like a project you build yourself it turns out to work much better if you start with the simplest possible version of the application and then iterate on it to add additional features.

One of my favorite details is how Git integration works. Phoenix.new commits constantly as it works, and a menu option for "Clone X to your local computer" then gives you a command that looks like this:

git clone "https://phoenix.new/git/WENQLj...big-random-string...VHFW/$RANDOM/notebook"

Run that locally to get a full copy of the repo! I ran the following to push it to a new repository in my GitHub account:

git remote add github https://github.com/simonw/phoenix-new-notebook.git
git push -u github main

You can see the code (and the commit history) in my simonw/phoenix-new-notebook repo.

How much did I learn?

My initial experiments with Phoenix.new were very much vibe coding - I interacted with the resulting application but didn't pay a great deal of attention to the code that was being written, despite it being presented to me in an IDE that made it very easy to review what was going on.

As a result, I didn't learn much about the low-level syntax details of how Phoenix and Elixir work. I did however get a strong feel for the shape of Elixir and Phoenix at a high level as the code danced past my eye.

It turns out having an LLM write an application in front of you is a great way to start building understanding of what a framework can do.

It’s almost like watching a YouTube livestream of an experienced developer speed running building an application, except that app is exactly what you asked them to build and you can interject and send them in a new direction at any moment.

Expanding beyond Elixir and Phoenix

Chris's announcement included this note:

At this point you might be wondering – can I just ask it to build a Rails app? Or an Expo React Native app? Or Svelte? Or Go?

Yes, you can.

Our system prompt is tuned for Phoenix today, but all languages you care about are already installed. We’re still figuring out where to take this, but adding new languages and frameworks definitely ranks highly in my plans.

The browser-based IDE includes a terminal, and I checked and python3 and python3 -m pip install datasette work there already.

If Fly do evolve this into a framework-agnostic tool for building web apps they'll probably need to rebrand it from Phoenix.new to something a bit more generic!

Phoenix.new is currently priced as a $20/month subscription. Val Town recently switched the pricing for their similar Townie assistant from a subscription to to pay per use, presumably because for many users this kind of tool is something they would only use intermittently, although given the capabilities of Phoenix.new it's possible it could become a monthly driver for people, especially as it expands out to cover more frameworks.

Fly sponsor some of our work on Datasette Cloud (see disclosures), but this article is not sponsored content and Fly did not request or review this post.

Tags: erlang, sqlite, ai, fly, generative-ai, llms, ai-assisted-programming, ai-agents, vibe-coding, coding-agents, prompt-to-app

ActorDB

2018-06-24T21:48:29+00:00

ActorDB

Distributed SQL database written in Erlang built on top of SQLite (on top of LMDB), adding replication using the raft consensus algorithm (so sharded with no single-points of failure) and a MySQL protocol interface. Interesting combination of technologies.

Tags: erlang, scaling, sqlite, big-data

Hot Code Loading in Node.js

2010-01-31T13:57:53+00:00

Hot Code Loading in Node.js

Blaine Cook’s patch for Node.js that enables Erlang-style hot code loading, so you can switch out your application logic without restarting the server or affecting existing requests. This could make deploying new versions of Node applications trivial. I’d love to see a Node hosting service that allows you to simply upload a script file and have it execute on the Web.

Tags: blaine-cook, deployment, erlang, javascript, nodejs

Introducing BERT and BERT-RPC

2009-10-21T22:11:37+00:00

Introducing BERT and BERT-RPC

Justification for inventing a brand new serialisation protocol: Thrift and Protocol Buffers both use IDLs and code generation, XML “is not convertible to a simple unambiguous data structure in any language I’ve ever used” and JSON lacks support for unencoded binary data. The result is BERT—Binary ERlang Term—which extracts a format from Erlang in much the same way that JSON extracted one from JavaScript.

Tags: erlang, github, javascript, json, protocolbuffers, serialisation, thrift, xml

How We Made GitHub Fast

2009-10-21T21:14:38+00:00

How We Made GitHub Fast

Detailed overview of the new GitHub architecture. It’s a lot more complicated than I would have expected—lots of moving parts are involved in ensuring they can scale horizontally when they need to. Interesting components include nginx, Unicorn, Rails, DRBD, HAProxy, Redis, Erlang, memcached, SSH, git and a bunch of interesting new open source projects produced by the GitHub team such as BERT/Ernie and ProxyMachine.

Tags: drbd, erlang, ernie, git, github, haproxy, memcached, nginx, proxymachine, rails, redis, replication, ruby, scaling, ssh, unicorn

PubSub-over-Webhooks with RabbitHub

2009-07-01T20:22:52+00:00

PubSub-over-Webhooks with RabbitHub

RabbitMQ, the Erlang-powered AMQP message queue, is growing an HTTP interface based on webhooks and PubSubHubBub.

Tags: amqp, erlang, http, message-queues, pubsubhubbub, rabbitmq, webhooks

Parallel merge sort in Erlang

2009-03-15T13:36:13+00:00

Parallel merge sort in Erlang

Thoughts on an Erlang-y way of implementing a combined activity stream (e.g. Facebook and Twitter). Activity streams are a Really Hard Problem—as far as I know there’s no best practise for implementing them yet.

Tags: activitystreams, erlang, facebook, twitter

GeoCouch: Geospatial queries with CouchDB

2008-10-27T23:48:46+00:00

GeoCouch: Geospatial queries with CouchDB

Interesting approach: uses “external2”, a branch that allows external services to be called from CouchDB. SQLite’s SpatiaLite extension is then used as an external spacial index.

Tags: couchdb, erlang, external2, geocouch, spatialite, sqlite

A Million-user Comet Application with Mochiweb, Part 1

2008-10-16T14:16:18+00:00

A Million-user Comet Application with Mochiweb, Part 1

Richard Jones explores Mochiweb, Erlang and linux kernel tuning for building a high performance comet server. Does this mean real-time web features are coming to last.fm?

Tags: comet, erlang, lastfm, mochiweb, realtimeweb, richard-jones

Reia

2008-09-25T18:12:59+00:00

Reia

The most common complaint I see about Erlang is the syntax. Reia is a Python-style scripting language (with a dash of Ruby) that runs on the Erlang virtual machine. Looks promising.

Tags: erlang, programming, python, reia, ruby

Engineering @ Facebook: Facebook Chat

2008-05-15T07:55:36+00:00

Engineering @ Facebook: Facebook Chat

The new Facebook Chat uses Comet (long polling with a hidden iframe) against a custom web / chat server written in Erlang, designed to handle a launch to all 70 million users at once. It was tested using a “dark launch” period where live pages simulated chat request traffic without showing any visible UI.

Tags: comet, darklaunch, erlang, facebook, javascript, scaling

Quoting Damien Katz

2008-04-14T15:17:39+00:00

Once you reach a certain level of activity in the system where the garbage collector can no longer keep up (and it will happen), then every line of code in your system is now a potential failure point that can leave the whole program in a bad state. Lisp has this problem. Java has this problem. Erlang does not.

— Damien Katz

Tags: damien-katz, erlang, faliure, garbagecollection, java, lisp

In Response to "What Sucks About Erlang"

2008-03-11T05:46:05+00:00

In Response to "What Sucks About Erlang"

Yariv Sadan responds to Damien’s criticism.

Tags: damien-katz, erlang, yarivsadan

What Sucks About Erlang

2008-03-11T05:45:16+00:00

What Sucks About Erlang

Damien Katz shares his greatest frustrations from working with Erlang on CouchDB.

Tags: couchdb, damien-katz, erlang

What You Need To Know About Amazon SimpleDB

2007-12-14T11:21:37+00:00

What You Need To Know About Amazon SimpleDB

Amazon have finally launched the database component of their web service suite. It fits a bunch of current trends: key/value pairs, schemaless, built on top of Erlang. “Eventual consistency” is an interesting characteristic.

Tags: amazon, charles-ying, databases, erlang, hashtables, scaling, schemaless, simpledb, web-services

ErlyWeb vs. Ruby on Rails EC2 Performance Showdown

2007-12-10T15:27:54+00:00

ErlyWeb vs. Ruby on Rails EC2 Performance Showdown

ErlyWeb’s peak response rate beats Rails by 47x, albeit with a hugely simplified benchmark. More interesting than the results is the idea of using EC2 for benchmarking on identical simulated hardware.

Tags: amazon, benchmarks, ec2, erlang, erlyweb, performance, rails, virtualisation, yarivsadan

CouchDB Roundup

2007-12-06T15:48:47+00:00

CouchDB Roundup

The CouchDB project is interested in contributions from people who can write a large file driver for Erlang, help figure out the CouchDB security model and build scripts to help benchmark performance, scalability and reliability.

Tags: couchdb, erlang, helpwanted

mochiweb - another faster web server

2007-11-09T23:22:37+00:00

mochiweb - another faster web server

Bob Ippolito’s latest project: a high performance Erlang web server.

Tags: bob-ippolito, erlang, mochiweb, webserver

CouchDB "Joins"

2007-10-25T08:27:27+00:00

CouchDB "Joins"

Different approaches to indexing a blog post and its associated comments in the non-relational CouchDB.

Tags: christopher-lenz, couchdb, databases, erlang, joins, relational, views

CouchDB first impressions

2007-10-19T11:43:11+00:00

CouchDB first impressions

Jacob’s been poking at CouchDB. Inserting data is slow, but everything else looks pretty slick considering how recently the JSON / JavaScript views functionality was added.

Tags: couchdb, erlang, jacob-kaplan-moss, javascript, json

How should JSON strings be represented in Erlang?

2007-09-14T08:17:05+00:00

How should JSON strings be represented in Erlang?

Erlang’s poor support for strings makes this a surprisingly tricky question.

Tags: erlang, json, strings, tonygarnockjones

An Introduction to Erlang

2007-09-13T17:47:24+00:00

An Introduction to Erlang

Erlang gets the ONLamp tutorial treatment from Gregory Brown.

Tags: erlang, gregory-brown, onlamp, programming

CouchDB: Thinking beyond the RDBMS

2007-09-03T09:48:43+00:00

CouchDB: Thinking beyond the RDBMS

CouchDB is a fascinating project—an Erlang powered non-relational database with a JSON API that lets you define “views” (really computed tables) based on JavaScript functions that execute using map/reduce. Damien Katz, the main developer currently works for MySQL and used to work on Lotus Notes.

Tags: couchdb, damien-katz, databases, erlang, javascript, json, lotusnotes, mapreduce, mysql