Live data from Hacker News

Phoenix.new – Remote AI Runtime for Phoenix

fly.io

81–90 of 283 posts

Re: Phoenix.new – Remote AI Runtime for Phoenix

#81

I've wasted a lot of time and energy on stuff that doesn't matter, so I can hardly judge anyone else on what they focus on, but man does it feel bad to have community leaders actively focus on building out tooling that is anti-worker. I think the only way I'd feel more conflicted is if Fly.io started building weapons systems for the military. I guess that wouldn't be shocking considering some of their lead's beliefs.

It's safe to say that if either Chris or I believed this to be anti worker, we wouldn't be working on it. He's spent the last 10+ years working on Phoenix specifically to improve the lives of the people doing the work.

My experience with software development is maybe different than yours. There's a massive amount of not-yet-built software that can improve peoples' lives, even in teeny tiny ways. Like 99.999% of what should exist, doesn't.

Building things faster with LLMs makes me more capable. It (so far) has not taken work away from the people I work with. It has made them more capable. We can all build better tools, and faster than we did 12 months ago.

Automation is disruptive to peoples' lives. I get that. It decreases the value of some hard earned skills. Developer automation, in my life at least, has also increased the value of other peoples' skills. I don't believe it's anti worker to build more tools for builders.

Re: Phoenix.new – Remote AI Runtime for Phoenix

#83

Phoenix creator here. I'm happy to answer any questions about this! Also worth noting that phoenix.new is a global Elixir cluster that spans the planet. If you sign up in Australia, you get an IDE and agent placed in Sydney.

This looks amazing! I keep loving Phoenix more the more I use it. I was curious what the pricing for this is? Is it normal fly pricing for an instance, and is there any AI cost or environment cost? And can it do multiple projects on different domains?

It’s $20 per month if you click through, and I haven’t tried it but almost certainly the normal hosting costs will be added on top.

Re: Phoenix.new – Remote AI Runtime for Phoenix

#84
post #43

Earlier quoted context omitted.

> I’ve used both the non official libraries and they work fine Maybe fine today but what about 5 years from now? Can you say, with any degree of confidence, if these these libraries are going to be properly maintained in the future? No, you cannot.

Goes for every library out there though. Official or not.

Not really. You can be much more confident the official AWS SDK will be available 5 or even 10 years from now.

Re: Phoenix.new – Remote AI Runtime for Phoenix

#85
post #67

Earlier quoted context omitted.

Any takeaways on using Fly APIs for provisioning isolated environments? I'm looking into doing something similar to Phoenix.new but for a low-code server-less workflow system.

1 week of work to go from local-only to fly provisioned IDE machines with all the proxying. fly-replay is the unsung hero in this case, that's how we can route the *.phx.run urls to your running dev servers, how we proxy `git push` to phoenix.new to your IDE's git server, and how we frame your app preview within the IDE in a way that works with Safari (cross origin websocket iframes are a no go). We're also doing a b…

Thanks, I might hit you up when I'm in the weeds of that feature.

Re: Phoenix.new – Remote AI Runtime for Phoenix

#86
post #28

Beautiful demo! How do I build agents like this? Does anyone know any great resources to learn how to design agents? Tool agnostic resources would be awesome.

Thanks! Everything is overly complicated in this space. It's probably far easier than you think. The open secret is it's just a loop that POST [provider]/chat/completions. Elixir is particularly well suited here. In Elixir this is a genserver doing http posts and reacting to the token stream. The LiveView chat gets messages from the genserver agent regardless of where it is on the planet, and the agent also communica…

Wow, thank you for the link, it clarified how tool calling and "choice-making" works.

It's like helping LLMs use a computer; like building an interface for it.

Ok, this is enough to get me started.

Re: Phoenix.new – Remote AI Runtime for Phoenix

#87
post #45

This is great. I had to back out of a phoenix project and rewrite it in Django because I couldn't get good AI assistance. I'm pretty inexperienced with Elixir and Phoenix but understand the benefits enough to want to make projects in it. So this is really cool.

I find that baffling. Why not just write the Elixir yourself?

Not just baffling, but concerning. LLM's are great for learning new languages, but terrible for outputting code you don't understand yet hope to maintain.

Re: Phoenix.new – Remote AI Runtime for Phoenix

#88
post #9

Earlier quoted context omitted.

Worried it might fall behind… further? I love LiveView, Phoenix, Elixir, OTP. But the ecosystem is a wasteland of abandoned packages. If Phoenix.new helps solve that problem, I’m all for the effort. But otherwise, the sole focus of the community leaders of Elixir should be squarely and exactly focused on creating the incentives and dynamics to grow the base. Compare, for example, Mastra in TypeScript or PydanticAI in…

All languages are a wasteland of abandoned packages, i.e. there is a very long tail of stuff no one has maintained for years. It’s all relative to the mindshare. For its size, Elixir is doing quite well.

It's not the long tail. It's that the HEAD of packages in Elixir are also often poorly maintained or not maintained. The fundamental question for any developer: can I be productive quickly? Despite all that Elixir has going for it, the answer is often "no."

Want a first-party client library for the service you're using? Typically the answer is "too bad, Elixir developer." And writing your own Finch or Req wrapper for their REST endpoint simply isn't a valid answer.

>For its size, Elixir is doing quite well.

I'm actually arguing the opposite. Elixir is not doing well because of its size. So how can that be influenced and changed?

Re: Phoenix.new – Remote AI Runtime for Phoenix

#89
post #10

Earlier quoted context omitted.

Same, I watched a video from Theo where he says Next.js and Python will be the best languages because LLMs know them well, but if the model can infer, it shouldn’t be a problem.

Folks on YouTube have used Claude Code and the new Tidewave.ai MCP (for Elixir and Rails) to vibe code a live polling app in Cursor without writing a line of code. The 2hr session is on YT.

This one?

https://www.youtube.com/live/V2b6QCPgFTk

Re: Phoenix.new – Remote AI Runtime for Phoenix

#90
post #21

I'm surprised they are investing into this. I checked Phoenix recently because I was interested in LiveView and there isn't even an official AWS SDK for Elixir. Honestly doubt the AI stuff is going to move the needle much if you can't even have a dependable S3 client.

Meanwhile I am a happy user of :ex_aws or :req_s3 which has done everything I need it to do. Object ops, iam policies, etc. A dependable S3 client has been there for years. The elixir core team doesn't need to maintain it. ReqS3 is one of my favorite things to use: https://hexdocs.pm/req_s3/readme.html

Maybe you can guarantee Phoenix will be maintained 5-10 years from now but that's really not the case for some random library on Github.

If you look around you'll see this kind of stuff is really one of the biggest blockers for Elxir and Phoenix. Especially for something as fundamental as cloud storage.

Post reply on HN