From the Gleam website FAQ regarding comparison to elixir:
Elixir code can be difficult to use from other BEAM languages, Gleam code is designed to be usable from all BEAM languages.
Is that true that Elixir interop is one-way? I know that it is very easy, for instance, to call on Erlang modules in Elixir code but does the converse not hold? What would be the reason for that difference with Gleam, both technically and pragmatically?
You can call elixir functions from erlang or gleam just fine. Where the issues are is elixir macro’s, which don’t work with anything else except elixir (since it happens at compile-time in the elixir compiler).
You can use macros in elixir code and then use the resulting elixir code from other BEAM languages, but you cannot use elixir macros directly in other BEAM languages. To put it differently, every macro must eventually resolve into modules and functions, the core building blocks of the BEAM. These modules and functions are independent of language once they are compiled, only identified by their module name, which will be an atom, their function name, also an atom, and their arity.
Another thing that makes it tricky to use Elixir from other languages is the way that the compiler and standard library is distributed. They are not part of the OTP distribution or a hex package, so if you ever add an Elixir package to your Erlang, Gleam, LFE, etc project you will then need to use the operating system package manager or similar to install the Elixir standard library and compiler.
The Gleam standard library is a hex package, and Gleam modules are pre-compiled before being uploaded to hex, so no additional tools or plug-ins need to be installed to use a Gleam package from other languages.
Are there any benefits to the Elixir model of distribution versus Gleam’s model or was it simply not a real consideration at the time the Elixir ecosystem was being established? I don’t know if this is true, but I can imagine there might be some security assurances in not delivering precompiled packages.
Yeah, I get it now. If you use a macro inside Elixir it turns into functions that can be called in other BEAM langs, but other BEAM langs can’t call Elixir macros directly because they don’t have access to the Elixir compiler to turn the macros into functions.
In addition to what was said, it is worth pointing out this is not exclusively an issue with Elixir. For example, Erlang has parse transforms and some libraries may need to work with Erlang AST, therefore any BEAM language that chooses to compile to Core Erlang, such as LFE, do not have access to tools like the GUI debugger or cover in OTP. Erlang parse transforms and features such as qlc are also incompatible with Elixir (and I assume with Gleam too).
However, Elixir macros are more common than parse transforms, so the issue is definitely more prominent. I am only mentioning this to give examples that interop is not always possible, even without macros.
EDIT: I would also add that macros are not such a big issue, because macros are Elixir features, and therefore it is expected you have to write Elixir in other to use them. It is like wanting to use Gleam type system from Elixir/Erlang. If you want types, then it is expected you are writing Gleam code. I believe the issues mentioned by @lpil are probably trickier for reusing Elixir in other languages.