[Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055
Mon Apr 25 11:22:32 CEST 2022
Łukasz Niemier <lukasz@REDACTED> 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
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
> 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-extracting 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
>> 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 language".
> It is meant only to explicitly mark situations when you want to pattern match
> 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.
More information about the erlang-questions