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

Sun Mar 24 22:00:21 CET 2019

Hello!

Calling Elixir from Erlang is similar problem to calling C++ from C.
Possible? In certain cases: yes, I've done that, the (mangled) function
name looks ugly - but there's no way to instantiate C++ templates from C as
the C compiler has no idea about them. Similarly the Erlang compiler has no
idea about Elixir macros.

However, I have an even crazier idea: rebar, mix, hex, etc. know only about
(some of the) BEAM-using languages. But we live in multilingual times, so a
project might use other languages (especially JavaScript) too. Wouldn't it
be cool if a single tool could manage those dependencies, maybe even
generate Erlang/Elixir server code and JavaScript client code from the
interface description... I feel like reinventing CORBA and its IDL :-)

Devon Estes <devon.c.estes@REDACTED> ezt írta (időpont: 2019. márc. 24.,
V, 19:46):

> What if it was allowed for package maintainers to publish pre-compiled
> BEAM files to Hex? I would imagine that everyone who is pushing packages to
> Hex also has the ability to compile those packages on the machine they’re
> using to publish.
>
> There are clearly a whole ton of reasons why that could be a bad idea (and
> probably wouldn’t even work for a large chunk of macro-heavy Elixir
> libraries that rely on Mix configuration to be present at compile time),
> but it would also make for the easiest story for cross-language library
> sharing.
>
> It pushes the compilation step from the user of a package to the
> maintainer of that package, but if CLI tools knew where to put these
> pre-compiled BEAM files so users didn’t have to think about it, then it
> could make usage of some libraries much easier.
>
> It could be an optional thing for those maintainers who want to go the
> extra mile to make cross-language use of their packages easier. I know I’d
> be happy to take that extra step when publishing new versions of Benchee if
> it meant Erlang/LFE/etc. users could have an easier time using it.
>
> Or it could just make everything worse and more complicated �� but it
> seemed like it was worth bringing up.
>
> Bryan Paxton <starbelly@REDACTED> schrieb am So. 24. März 2019 um 17:50:
>
>>
>> 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
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
> --
>
> _________________
> Devon Estes
> 203.559.0323
> www.devonestes.com
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190324/a02c2935/attachment.htm>