My question here is why not use Elixir for this?
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?".
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.
observer:start()
vs.
:observer.start()
Regardless I agree with others saying beam sounds great for agents, a perfect fit
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.
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.
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.
That’s not a criticism of erlang. That’s a comment on my personal limitations of time.
I posted this because I got some funny outputs (read: deep research quality from gpt-4o over 37 minutes) with a derived repo using this repo, so I figured it was usable enough for others in this immediate space.
If you have any desired functionality, or you want to contribute, please file issues + file pull requests.
I have also been in the Elixir space for around 10 years, so we're in good company! 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.
give me macros and I'd be happy (not preprocessor stuff, not parse transforms)
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...
Thanks for mentioning this, it seems I did indeed commit a lot of binary executable files
Whoopsie
I think a good start could be rebar3's new app output.
rebar3 new app myapp
I want to be as close to the BEAM VM as possible
pancsta•9mo ago
[0] https://github.com/pancsta/secai