[erlang-questions] Elixir community, please be more responsible; Erlang community, please demand it.

[Bryan Paxton]

On 3/24/19 11:26 AM, Joe Armstrong wrote:
> On Sun, Mar 24, 2019 at 1:54 PM Fred Hebert <mononcqc@REDACTED> wrote:
>> On 03/24, Joe Armstrong wrote:
>>> I for one welcome all the things the Elixir folks are doing - but I
>>> have noticed the following:
>>>
>>> - Elixir folks are re-using Erlang libraries
>>> - Erlang folks are not (it seems to me) reusing Elixir libraries
>>>
>>> The "how to call Erlang from Elixir" documentation is great - the
>>> opposite "how to call Elixir from Elixir" is not (or have I missed something)
>>>
>>> Things like nerves, scenic, Phoenix etc. look great to me - but seem to be used
>>> almost exclusively by Elixir folks.
>>>
>>> Has anybody made, for example, a pure Erlang interface to scenic?
>>>
>> Well, there are some limitations there.
>>
>> - You can use mix to build your Erlang project and then use Elixir in
>>   there
>> - You can use rebar3 with the rebar_mix plugin (along with an Elixir
>>   install) to build Elixir dependencies (see
>>   https://github.com/tsloughter/rebar_mix)
>>
>> But in all cases, you will not necessarily be able to use Elixir code
>> when it heavily relies on macros at the call-site rather than
>> internally. So for example, a lot of usage of _plugs_ in Phoenix rely on
>> macros running within the controller compilation step to read the
>> declaration and inline them "somewhere??" with no obvious way to do it
>> without the macros.
>>
>> That specific stuff that relies on macros in _your Elixir code_ cannot
>> be ported to work with _your Erlang code_, because, well, we don't have
>> the same macro mechanisms available. Similarly, Erlang parse transforms
>> may not remain fully applicable to Elixir modules in the future.
>>
>> This means that Ecto, which is a huge part of a lot of web framework
>> usage, also won't be usable for Erlang users, since it is very
>> macro-dependent.
> Interesting - I'd imagined that after compilation you'd just end up
> with beam code files after which you could call them from Erlang ...
>
> Could this be rectified by a "better" macro processor for erlang - more
> in the style of the Elixir macro processor ???


 I'd like to add on top of this the smallest part of the problem, but
what I see as a problem none the less...

'ManyWouldPrefer':'not_to_have_to_do_this?'(Please)


As stated, smallest of all the problems, but whether we like it or not
UX matters. This not only applies to using Elixir but LFE, etc.  The
only solutions to that problem that I could think of involve perhaps too
much trickery, not really sure how the community feels about said
trickery though. That is to say, to squash this problem effectively
you'd have to translate/generate modules in other BEAM languages to pure
erlang (or generate pure erlang interfaces), prefix the module names
with 'elixir_' or 'lfe_' and then hack the compiler, shell, etc. to
treat this as special so that in the end we would be using
many_would_prefer:not_to_have_to_do_this(Please). Or instead of said
trickery, elixir_many_would_prefer:not_to_have_to_do_this(Please).

 This brings me to another point and something I didn't understand until
recently. Yes, with the rebar_mix plugin and so forth you end up using
the artifact (beam file) compiled by the given beam language. As Tristan
said, this requires you to have Elixir installed... it's not that big of
a deal perhaps... but say you would simply like to bring in emj's
Decimal lib as pointed out by Tristan... Do you really want to bring in
all of Elixir just to use said lib? It seems a bit much. This is
precisely why I "ported" Elixir's Version module to pure Erlang. Now,
you don't need to bring in Elixir to use a fully compatible semver
lib... but it's wrong... I felt bad in doing it... there is now more
code in the world and that's the last thing we need.

 What I want (dreams and wishes):

  Universal BEAM/Erlang libs. It would be the bees knees and a HUGE win
for the entire community for all to seamlessly be able use erlang,
elixir, lfe, <insert all the other BEAM langs here> without having to
bring in the entire language. If I'm not using the language directly,
why do I need that? How this could be achieved, have no idea, erlang
core perhaps... perhaps it's more complicated than that... 


--

Bryan


>
>> But if you look at other libraries (or frameworks) such as Raxx
>> (https://github.com/CrowdHailer/raxx), then this is a framework that is
>> fully written in Elixir, yet usable from Erlang (there's a demo at
>> https://github.com/CrowdHailer/greetings-ace-raxx-erlang-example).
>> Similarly, a library such as https://github.com/ericmj/decimal for
>> arbitrary precision arithmetic should be fine to use.
>>
>> This stuff has been available to rebar3 users since around late 2018, so
>> I assume it has seen slow adoption due to its being rather new, but we
>> (rebar3 maintainers) are confident that this bigger interplay is worth
>> it and should be seeing adoption over time.
>>
>> Finally, the stuff we're setting up with the Erlang Ecosystem Foundation
>> is also aimed at making language interplay easier for all languages of
>> the ecosystem.
> This would be great
>
> /Joe