Do you have a good example of a rebar3 application / umbrella app that would be good to copy in terms of structure? It has been a minute since I last touched erlang so I haven't really set up a proper directory structure myself before. Maybe I should just create a newbranch and try to set it up using Hex or something, not sure
Thanks for mentioning this, it seems I did indeed commit a lot of binary executable files
Ah no worries at all. Thanks for sharing your library!
I think a good start could be rebar3's new app output.
rebar3 new app myapp
That generates a src directory, a rebar.config file and a .gitignore file. The .gitignore would help keep the beams files out of git. If want others to use your project as a library from Erlang and Elixir an app structure is probably better?
Yeah, I would prefer to use Erlang here as I am making this a foundational library for a very large distributed system that I am migrating away from Python to probably Erlang + Rust for an AGI self play project
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?
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.
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.
I’ve never needed to use erlang in all these years. I have to imagine I’m not alone in finding erlang’s syntax more cryptic, given that erlang hit a limit and elixir broke through to a much wider audience. I don’t know what would make me a more “serious” developer though, having successfully built a few mission critical apps with elixir.
I have built one supervision tree and built GenServers, but I haven’t done much more OTP or cluster and node communications, if that’s what you meant. I’m genuinely curious about what you mean by serious elixir developer.
Well you yourself mentioned being hesitant to add a library that could likely help you solely based on it being in Erlang.
Erlang has many useful libraries, it's been around far longer. If everything has to be wrapped by Elixir to be useful, well that seems like a pretty significant limitation.
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
> 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?".
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.
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
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.
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
Elixir is only "better" because of the syntax and some of the developer experience. Anything good about Elixir is present in Erlang and likely originated there.
Erlang is strictly better in all ways for my use-case due to its purity, rigorous simplicity, and direct closeness to the BEAM VM. I also wrote a library 10 years ago to do python->elixir and back. https://github.com/stochastic-thread/snek.ex
When building foundational libraries, especially for large-scale distributed systems or agent-based architectures - I find Erlang’s minimalism, mature toolset (like `observer:start` for visual supervision trees), and battle-tested concurrency model invaluable. I also liked Prolog, so I guess if these preferences are strange, that explains them!
That said, Elixir definitely has enhanced the developer experience significantly. The improved syntax, great macros, `mix`, Hex package management, and community-driven tooling are impressive and inviting for newcomers. Interoperability is excellent, so writing foundational libraries in Erlang makes them readily accessible to Elixir applications without hassle.
A few examples highlighting Erlang’s advantages:
* *Minimalism & Predictability*: Erlang's restricted syntax and clear semantics make large-scale codebases easier to maintain and reason about, crucial when debugging complex distributed agent interactions.
* *Tooling & Debugging*: Tools like `observer:start`, built-in tracing with `dbg`, and mature profiling support give unparalleled visibility into running systems.
* *Closer to BEAM*: By writing directly in Erlang, I have tighter control and deeper understanding of how my code interacts with BEAM’s scheduling, garbage collection, and process handling.
Still—I love Elixir’s conveniences and often reach for it for web-facing layers, prototyping, or anything user-facing. Both languages complement each other well.
And yes, given my project's name (`Agents.erl`), maybe Elixir needs to rename its `Agent` module now.
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?
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...
Do you have a good example of a rebar3 application / umbrella app that would be good to copy in terms of structure? It has been a minute since I last touched erlang so I haven't really set up a proper directory structure myself before. Maybe I should just create a newbranch and try to set it up using Hex or something, not sure
Thanks for mentioning this, it seems I did indeed commit a lot of binary executable files
Whoopsie
Ah no worries at all. Thanks for sharing your library!
I think a good start could be rebar3's new app output.
That generates a src directory, a rebar.config file and a .gitignore file. The .gitignore would help keep the beams files out of git. If want others to use your project as a library from Erlang and Elixir an app structure is probably better?Yeah, I would prefer to use Erlang here as I am making this a foundational library for a very large distributed system that I am migrating away from Python to probably Erlang + Rust for an AGI self play project
I want to be as close to the BEAM VM as possible
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?
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?
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.
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.
I’ve never needed to use erlang in all these years. I have to imagine I’m not alone in finding erlang’s syntax more cryptic, given that erlang hit a limit and elixir broke through to a much wider audience. I don’t know what would make me a more “serious” developer though, having successfully built a few mission critical apps with elixir.
I have built one supervision tree and built GenServers, but I haven’t done much more OTP or cluster and node communications, if that’s what you meant. I’m genuinely curious about what you mean by serious elixir developer.
Well you yourself mentioned being hesitant to add a library that could likely help you solely based on it being in Erlang.
Erlang has many useful libraries, it's been around far longer. If everything has to be wrapped by Elixir to be useful, well that seems like a pretty significant limitation.
One great thing from erlang to be aware of is observer:start, or :observer.start in iex, to check out process supervision trees
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
I guess bias towards the language, its design and syntax.
> 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?".
Elixir vs erlang isn’t really the same kind of obnoxious “rewrite everything” suggestion as the other examples
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.
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
> 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.
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
Elixir is only "better" because of the syntax and some of the developer experience. Anything good about Elixir is present in Erlang and likely originated there.
Erlang is strictly better in all ways for my use-case due to its purity, rigorous simplicity, and direct closeness to the BEAM VM. I also wrote a library 10 years ago to do python->elixir and back. https://github.com/stochastic-thread/snek.ex
When building foundational libraries, especially for large-scale distributed systems or agent-based architectures - I find Erlang’s minimalism, mature toolset (like `observer:start` for visual supervision trees), and battle-tested concurrency model invaluable. I also liked Prolog, so I guess if these preferences are strange, that explains them!
That said, Elixir definitely has enhanced the developer experience significantly. The improved syntax, great macros, `mix`, Hex package management, and community-driven tooling are impressive and inviting for newcomers. Interoperability is excellent, so writing foundational libraries in Erlang makes them readily accessible to Elixir applications without hassle.
A few examples highlighting Erlang’s advantages:
* *Minimalism & Predictability*: Erlang's restricted syntax and clear semantics make large-scale codebases easier to maintain and reason about, crucial when debugging complex distributed agent interactions. * *Tooling & Debugging*: Tools like `observer:start`, built-in tracing with `dbg`, and mature profiling support give unparalleled visibility into running systems. * *Closer to BEAM*: By writing directly in Erlang, I have tighter control and deeper understanding of how my code interacts with BEAM’s scheduling, garbage collection, and process handling.
Still—I love Elixir’s conveniences and often reach for it for web-facing layers, prototyping, or anything user-facing. Both languages complement each other well.
And yes, given my project's name (`Agents.erl`), maybe Elixir needs to rename its `Agent` module now.
related for Elixir: https://goto-code.com/blog/elixir-otp-for-llms/
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