A lot of people would though, they’d like to, for example, use ecto from erlang or gleam, but you can’t, because it’s a macro library, lol.
OvermindDL1
stevensonmt
@OvermindDL1, if the above is true and the conditional statements are macros, and Elixir macros preclude interop, how is it possible to call any Elixir code in other BEAM languages?
0
John-Goff
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.
4
lpil
Creator of Gleam
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.
6
stevensonmt
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.
0
lpil
Creator of Gleam
RE security, the Gleam code is preconpiled to human readable Erlang code and it is shown on Hex Diff, so there’s no concerns there.
Elixir predates Hex, that’s almost certainly the reason for this design. That and having a special distribution approach for the standard library is quite common.
I think it would be possible to distribute Elixir entirely via Hex, but I doubt there’s much incentive to make such a large change to how the entire Elixir ecosystem works.
4
OvermindDL1
Why wouldn’t they? Macro’s run at elixir compile-time, whatever code the macro’s end up generating is just normal beam code that anything else can call.
2
stevensonmt
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.
2
josevalim
Creator of Elixir
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.
7
lpil
Creator of Gleam
I will say I get asked quite frequently about both how to use Elixir macros in Gleam and how to use Gleam to type check Elixir code. I think it can be hard to understand what the limitations of languages are.
I think there’s still plenty of improvements we can make without any disruptive changes to Elixir. Interop will continue to get better over the coming years
10