Re: [Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055

Nicolas Martyanoff <[email protected]> Mon, 25 Apr 2022 11:22:32 +0200
Newsgroups gmane.comp.lang.erlang.general
Message-ID <[email protected]>
=C5=81ukasz Niemier <[email protected]> writes:

>> - Improve dialyzer to work as other modern type annotation systems (i.e.
>>  treat type annotations as the truth and signal errors when the code
>>  does not satisfy them), and make its output readable.
>
> There is work on Gradualizer which seems like faster and better
> Dialyzer alternative.
When I tried it, it was interesting but far from production readiness.
It simply was not ready for maps (yet another problem, there should a
proper record system which is *not* based on preprocessor tricks).

This kind of tool should be part of Erlang/OTP and maintained by Ericsson.

>> - Introduce a standard build/package system with dependency support,
>>  similar to go mod (for all its faults, it works).
>
> There is already Hex.pm that does exactly that. And IIRC there were plans=
 to make
> Rebar3 part of the OTP.
Hex.pm has nothing to do with associating packages to my project with
the right version. It is a third party website forcing everyone in a
global namespace.

Rebar3 is clearly not part of OTP, it is still a third party tool which
has to work around OTP (see the numerous hacks in relx and rebar3).

>> - Add a way to build self-contained single executables (again, something
>>  Go.
>
> That is pretty hard to do, as Erlang requires some external libraries in =
most cases
> (OpenSSL for example) and it is hard to make them in such "single binary"=
. There are
> tools that make it a little bit easier though (these create self-extracti=
ng archives).
> This however is still not super easy, as the VM need to be compiled
> for target machine.
Of course it is hard. But this is actually useful. Solving the NIF
situation, i.e. having a way to ship an escript with NIFs, would be a
good start.

>> And the list could go on for pages, without having to destroy the basic
>> concepts of the language.
>
> I do not understand how this proposal destroys "basic concept of the lang=
uage".
> It is meant only to explicitly mark situations when you want to pattern m=
atch
> on existing binding to avoid some headaches and to allow some
> readability improvements.
There is no point in debating that point, it is obvious that the
proposal divides the entire community.

--=20
Nicolas Martyanoff
http://snowsyn.net
[email protected]