Absolutely!

Elixir's lightweight processes and distribution story make it ideal for orchestration, and that includes orchestrating LLMs.

Shameless plug, but that's what many people have been using Oban Pro's Workflows for recently, and something we demonstrated in our "Cascading Workflows" article: https://oban.pro/articles/weaving-stories-with-cascading-wor...

Unlike hatchet, it actually runs locally, in your own application as well.

If it had a larger learning base, quite possibly.

Erlang possibly even more so. The argument that pure code is generally safer to vibe code is compelling to me. (Elixir's purity is rather complicated to describe, Erlang's much more obvious and clear.) It's easier to analyze that this bit of code doesn't reach out and break something else along the way.

Though it would be nice to have a language popular enough for the LLMs to work well on, that was pure, but that was also fast. At the moment writing in pure code means taking a fairly substantial performance hit, and I'm not talking about the O(n log n) algorithm slowdowns, I mean just normal performance.

Well elixir doesn't produce goroutines (managed threads), they produce "lightweight processes" which have isolated memory. These are more expensive to grow and aren't as easy to share data between one another, although they're much more fault tolerant as a result. It could be better however the underlying concurrency model in Elixir is relatively unique

It's been a while since I was in the weeds on this, but if I remember correctly they're strictly speaking mostly isolated. Binaries above a certain size share storage between processes, so moving big blobs between processes is cheap.

They also have their own system to share data between processes, although I haven't used it. Generally though it's a unique tool that's not always interchangeable with Go

> also the link at the bottom of the page is pretty much why I ditched Go: https://go.dev/blog/error-syntax

Funnily, it's also one of the reasons I stay with Go.

Error handling is the most contraversial Go topic, with half the people saying it's terrible and needs a new syntax, and half saying it's perfect and adding any more syntax will ruin it.

by your logic, only considering part of the argument is as good as considering the entire argument.

I don't use either Go or LLMs, but isn't the point of LLMs that they write the tedious boilerplate for you? What's the value in a small syntactic improvement if the computer is generating it all anyway?

Elixir's concurrency model is fundamentally different than Go's; it's not just syntax difference.

Elixir is great for agents.

This makes me want to build agents in Elixir now