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).
I love that he basically wrote a guide on how to do it and then asked if there were such a guide at the end.
Does that include built-in macros like if/2?
Note: An interesting note regarding
if/2andunless/2is that they are implemented as macros in the language; they aren’t special language constructs as they would be in many languages.
I am not sure I follow. To call elixir functions from outside, one would still need a beam file, to produce it one needs elixir compiler, which would in turn expand macros.
That said, I don’t see any special issue with macros.
def is a macro, defmodule is a macro, defmacro is a macro, after all. Macros are expanded into AST, there won’t be any issues with them, AFAICT.
Try building an ecto query within an erlang module. That won’t work.
Yes, that’s a macro, not a function.
Yes, and after expansion the macro’s no longer exist, only functions remain, hence why you can call elixir functions from other languages, but you cannot call elixir macro’s from other languages.
The ‘big’ elixir libraries use macro’s heavily, hence why they aren’t really useful outside of elixir.
The issue is that it’s the elixir compiler that expands the macro’s, not other languages, hence why another language can’t call an elixir macro (usefully anyway).
Ah, got it, thanks for the clarification! I would not expect people to directly call macros from outside.
Got it. I simply missed the possibility that one would expect calling macros from outside to work.
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, 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?
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.
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.
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.
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.
© Copyright Elixir Forum | Terms | Privacy & Cookies
