I really like the focus on “data and pure functions” from the beginning of the post.
I’ve read a lot on HN about how BEAM execution model is perfect for AI. I think a crucial part that’s usually missing in LLM-focused libraries is the robustness story in the face of node failures, rolling deployments, etc. There’s a misconception about Elixir (demonstrated in one of the claw comments below) that it provides location transparency - it ain’t so. You can have the most robust OTP node, but if you commit to an agent inside a long running process, it will go down when the node does.
Having clear, pure agent state between every API call step goes a long way towards solving that - put it in Mnesia or Redis, pick up on another node when the original is decommissioned. Checkpointing is the solution
My strongest opinion with Jido is that agents must be architecturally correct WITHOUT LLM's before they can be correct WITH LLM's
Jido core has zero LLM support for this reason.
There's nearing 40+ years of "Agent" research in CompSci, LLM's came along and we threw out all of it. I didn't like that so I spent time researching this history to do my best at considering it with Jido.
That said, I love LLM's - but they belong in the Jido AI package.
Fair enough! My comment is about agentic-focused libraries in general, it’s inaccurate of me to call all such libraries “LLM-focused”
Speaking of inaccuracies, BEAM does provide pretty good location transparency - but resource migration between nodes in particular is not part of the built-in goodies that OTP brings
We also had a similar use case, so I built Snex[0] - specifically for Elixir-Python interop. Elixir-side spawns interpreters with Ports managed by GenServers, Python-side has a thin asyncio runtime to run arbitrary user code. Declarative environments (uv), optimized serde with language-specific objects (like `%MapSet{}` <-> `set`), etc. Interpreters are meant to be long lived, so you pay for initialization once.
It's a very different approach than ex_cmd, as it's not really focused on the "streaming data" use case. Mine is a very command/reply oriented approach, though the commands can flow both ways (calling BEAM modules from Python). The assumption is that big data is passed around out of band; I may have to revisit that.
These are spoofed packets for SYNACK reflection attacks. Your response traffic goes to the victim, and since network stacks are usually configured to retry SYNACK a few times, they also get amplification out of it
There is a solution to that, but it requires these companies to implement source address validation. If your ISP is on the list, maybe complain about it.
personally, i like that raku goes the other way, with exported bits of the interface explicitly tagged using `is export` (which also allows for the creation of selectably importable subsets of the module through keyed export/import with `is export(:batteries)`/`use TheModule :batteries`, e.g. for a more featureful interface with a cost not every user of the module wants to pay).
it feels more natural to me to explicitly manage what gets exported and how at a different level than the keyword used to define something. i don't dislike rust's solution per se, but if you're someone like me who still instinctually does start-of-line relative searches for definitions, suddenly `fn` and `pub fn` are separate namespaces (possibly without clear indication which has the definition i'm looking for)
Actually, a module can implement any export heuristics by supplying an EXPORT subroutine, which takes positional arguments from the `use` statement, and is expected to return a Map with the items that should be exported. For example:
sub EXPORT() { Map.new: "&frobnicate" => &sum }
would import the core's "sum" routine, but call it "frobnicate" in the imported scope.
Note that the EXPORT sub can also be a multi, if you'd like different behaviour for different arguments.
neat! i've never needed more than i could get away with by just sneaking the base stuff into the mandatory exports and keying the rest off a single arg, but that'll be handy when i do.
Oh nice, I didn't know about that one! It's interesting how many solutions are in this space; aside from Destructure[0] and shorter_maps[1] I also know about shorthand[2] and synex[3].
There was also a relatively popular fork shorter_maps [0], mentioned in the blog post above. My motivation for implementing es6_maps instead of using/updating shorter_maps was (I'm copying from my post in the Elixir forums [1]):
1. I do firmly believe this is a good language feature and a very natural extension of map literals syntax;
2. at the same time, being a language feature it should be simple - es6_maps works only with atom keys and has no extra features over the key expansion.
Point 1 is additionally reinforced by how easy it was to introduce to the compiler - I’m injecting just 9 lines of simple code, while parser and lexer already accept short-form maps without modifications.
> I think the formatter plugin is going to give someone insane amounts of regret one day
The formatter plugin features a "reverse" flag exactly to prevent any kind of regret like that. You can reformat your code automatically to remove all shorthand maps and remove the dependency in a couple simple steps.
> I’d really encourage you to put a note at the top of the readme that this shouldn’t be used in production code.
Noted, although I do think it's production ready. I'm going to keep updating the library if or when a new version of the Elixir compiler breaks it, and it does feature an easy way out in case I disappear.
I’ve read a lot on HN about how BEAM execution model is perfect for AI. I think a crucial part that’s usually missing in LLM-focused libraries is the robustness story in the face of node failures, rolling deployments, etc. There’s a misconception about Elixir (demonstrated in one of the claw comments below) that it provides location transparency - it ain’t so. You can have the most robust OTP node, but if you commit to an agent inside a long running process, it will go down when the node does.
Having clear, pure agent state between every API call step goes a long way towards solving that - put it in Mnesia or Redis, pick up on another node when the original is decommissioned. Checkpointing is the solution
reply