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]