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

Sun Mar 24 19:46:03 CET 2019

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190324/bf275570/attachment.htm>