Remix.run Logo
grimgrin 2 days ago

right, you're using the tool for the job. author was reaching for reliability, re: OTP/beam. now we don't know if they actually needed it, but, you're saying the same thing to me

bicx a day ago | parent | next [-]

It was the BEAM process/actor model that fit much better for managing agents, and then there was the out-of-the-box live UI with Phoenix/LiveView that was really appealing. I had started the project in Typescript/Node (because that's my company's primary stack choice), but it hit a plateau in reliably managing multiple independent long-lived agent processes (not really what Node is designed for). I could have used an even more boring tech like Go with more robust process management, but Elixir and Phoenix also came with a lot out of the box. It's no surprise that OpenAI's reference project for agent orchestration (https://github.com/openai/symphony) is also written in Elixir.

catchnear4321 2 days ago | parent | prev [-]

i see one person saying it is now cheap to support the new hotness, which previously would have been its own project, and another saying it has become cheap again to do things the boring-yet-reliable way that maybe didn’t used to scale so great.

grimgrin a day ago | parent [-]

that's fair. probably i attached more weight to the opening line: "We're in an interesting time where my framework/stack choice is now much less dictated by existing engineer expertise and more about fundamental capabilities in the framework and stack themselves."

assuming author wouldn't choose X _just because_ it is the new hotness