[HN Gopher] Show HN: Agents.erl (AI Agents in Erlang)
       ___________________________________________________________________
        
       Show HN: Agents.erl (AI Agents in Erlang)
        
       Author : arthurcolle
       Score  : 29 points
       Date   : 2025-05-07 01:42 UTC (2 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | pancsta wrote:
       | It's nice to see that BEAM is still alive. If you're into actor
       | model / state machine agents, I can recommend secai, which is in
       | Golang [0]. It does have a form of goroutine cancellation. Do you
       | happen to have some screenshots of your devflow in beam? How do
       | you debug?
       | 
       | [0] https://github.com/pancsta/secai
        
       | dpflan wrote:
       | BEAM seems like a great infrastructure for developing AI/ML
       | agents and interactions among different processes that can be
       | agents or functions.
       | 
       | My question here is why not use Elixir for this?
        
         | doomspork wrote:
         | I love Elixir but I'm curious about your question: why not use
         | Erlang for this? What would using Elixir do for this that can't
         | be achieved with Erlang?
        
           | dpflan wrote:
           | I guess bias towards the language, its design and syntax.
        
             | rdtsc wrote:
             | > I guess bias towards the language, its design and syntax.
             | 
             | Ok, but the way the question is framed ("why not use Elixir
             | for this?") presents it like some kind of an universal
             | obvious choice. But I (and I guess the gp poster) don't see
             | the "obviousness" of it so to speak.
             | 
             | It's kind of like commenting on every single C or C++ code
             | link, "why not use Rust for this?" or "why not use Zig?".
        
               | photonthug wrote:
               | Elixir vs erlang isn't really the same kind of obnoxious
               | "rewrite everything" suggestion as the other examples
        
               | rdtsc wrote:
               | I think it's about the same level of effort when it's not
               | followed by specific suggestions or pointers about what's
               | better for this project, what modules functions might
               | disappear with improved abstractions with a different
               | language etc.
        
               | photonthug wrote:
               | https://elixirschool.com/en/lessons/intermediate/erlang
               | 
               | Interoperability makes them very companionable so it's
               | not really a rewrite situation. Whichever you have I bet
               | you can code generate your way almost all the way to a
               | fairly complete wrapper of the other. Way simpler than
               | most stuff like FFI, although I'm not aware of all the
               | details of any type conversion gotchas or similar. I've
               | never been lucky enough to actually work on this stuff
               | professionally
               | 
               | but rather than a rewrite I think it's more a question of
               | which representation is first, primary, or at the bottom
               | of the stack. Would be nice to hear more from an expert
               | though
        
               | rdtsc wrote:
               | > Interoperability makes them very companionable
               | 
               | The syntax is different, but they can call libraries from
               | other each. I guess are you thinking from the perspective
               | of someone using this library in their code? Well, that
               | argues for writing it in Erlang, since it is simpler to
               | use Erlang from Elixir than vice-versa.
        
           | photonthug wrote:
           | Assuming you want people to adopt and grow it? Elixir seems a
           | better choice. on the other hand if you start with erlang I
           | think you get elixir interop with little to no effort,
           | whereas the reverse is not as true.
           | 
           | Regardless I agree with others saying beam sounds great for
           | agents, a perfect fit
        
           | atonse wrote:
           | I am literally debugging an issue with our OpenAI client in
           | our Elixir app due to connections mysteriously timing out and
           | closing, and I think this sort of library might be really
           | good for enabling more widespread use of OpenAI stuff in our
           | app.
           | 
           | But since it's Erlang, I hesitate to add this since I don't
           | want to now start debugging stuff in Erlang. And I've coded
           | full-time with Elixir since 2016/2017 time frame.
           | 
           | So I'm biased here, but I definitely would try this out if it
           | were Elixir, but the Erlang gives me pause since it still is
           | a pretty different language, and I'd have a hard time
           | debugging any issues.
        
             | doomspork wrote:
             | Learning Erlang and understanding it is an important skill
             | for any serious Elixir developer. Erlang has been around
             | longer and has a larger set of available tools, it's what
             | Elixir piggybacks on, and we can't just rewrite everything
             | in Elixir.
        
         | guywithahat wrote:
         | I've always felt the same way, but now that I'm reading the
         | Erlang code in this codebase I don't see the issue. Erlang is a
         | pleasant language to look at, and I wonder if all the hype I
         | believed about Elixir being better maybe wasn't true after all
        
         | strawhatdev wrote:
         | related for Elixir: https://goto-code.com/blog/elixir-otp-for-
         | llms/
        
       | rdtsc wrote:
       | Looks great, thanks for sharing!
       | 
       | I just noticed you committed your .beam files and the _build
       | directory. I think that's a bit unusual.
       | 
       | If you don't use specific features of jsx and can restrict
       | compatibility to more recent versions of Erlang/OTP (27+) you
       | might be able to use the built-in json module
       | https://erlang.org/documentation/doc-15.0-rc3/lib/stdlib-6.0...
        
       ___________________________________________________________________
       (page generated 2025-05-09 23:01 UTC)