Re: Support for non-unique process labels?

Łukasz Niemier <[email protected]> writes:
> I agree there. I would also love to hear what is missing in Erlang ecosystem. Especially as
> SpawnFest is coming, so if something can be improved, then it will be great opportunity to
> do so.

If we are talking about the ecosystem, and especially tooling:

- Erlang still requires an external tool to build projects and handle
  their dependencies.

- Building runtime-independant executables means dealing with
  releases, a packaging mechanism so complex that people use it through
  two different abstraction layers (rebar3 then relx). Go demonstrated
  how valuable it is to be able to simply build an executable that just
  works. I am aware that dealing with code upgrade is hard. I am also
  aware that lots of developers do not use it, but still have to pay the
  price with releases.

- EScripts are still a hack, and building an escript using dependencies
  without rebar3 is, again, way to complex. And you cannot use NIFs.

- In general, it should be simple to write applications, and to handle
  multiple applications in a single project.

- Dialyzer may be usually right (I have no proof of any wrong diagnostic
  in years of Erlang, which is good), but its reporting is incredibly
  hard to decipher. Good luck understanding what went wrong in a 80
  lines message because it expands all types during reporting. And do we
  really need dozens of messages about functions never being called
  because somewhere in the call chain, Dialyer decided that an
  expression will never match ?

  It also does not seem to make up its mind about trusting definitions
  or trusting type inference. I need Dialyzer to tell me when the code
  is wrong according to my definition, not to decide on its own that my
  definitions are incorrect.

  And unless I'm mistaken, it does not analyze thrown values and whether
  they match when being caught.
  
-- 
Nicolas Martyanoff
http://snowsyn.net
[email protected]