[rdtsc]

> 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]

Elixir vs erlang isn’t really the same kind of obnoxious “rewrite everything” suggestion as the other examples

[rdtsc]

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]

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]

> 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.

[arthurcolle]

yeah

observer:start()

vs.

:observer.start()