Support for non-unique process labels?

[Nicolas Martyanoff]

Łukasz Niemier <lukasz@REDACTED> writes:

>> does not handle timezone computations,
>
> Because that is hard, really hard. Additionally that would require Erlang
> to somehow store, process, and update TZ database. That is why this isn't
> built in and it is expected to use external libraries. See that Elixir,
> while providing functions for working with the TZ, it by default work only
> with UTC, because it doesn't know about any other TZ.
Oh I'm aware of the difficulty, I implemented iCal some times ago. And
yet all other languages I use support it in their standard library. I am
even writing an Erlang time/date library because at some point, this is
my only option, and having to do that is quite annoying.

> [...]
I get it, everything is hard. So is writing a compiler, let us remove it
from Erlang/OTP et let people use an external one. The point is for
Erlang/OTP to be a set useful tools to write applications, not to be a
collection of simple things.

>> And do not get me started on the string/binary insany.
> What is insane there?
There is no type difference between a string (i.e. a list of integers),
and a… list of integers. You cannot match values to know if they are
strings or lists. Good luck representing, e.g. JSON values, if you use
strings. And I am not even talking about performances, given how many
people simply do not want to accept it.

Ultimately everyone ends up using only binaries. Which is annoying
('<<"' / '">>' for literals), and forces to do a lot of conversions
because lots of parts of the standard libraries are stuck with strings.

Using binaries for strings is the best thing Elixir did, of all other
features.

> There are proposals to change that. However it is not true that Erlang do
> not support NaNs, it "support" them, but only sNaNs while not supporting
> qNaNs like other languages.
No it does not. There is no representation for a NaN or infinite value,
and there is no way to control the result of IEEE.754 invalid operations
(since Erlang chose to only signal errors, which is incredibly
unpractical for various numerical computations). And there is no
difference between -0.0 and +0.0.

>> Of course httpc/httpd is perfectly fine. Right.
>
> Even in "network languages" like Go you need to use external libraries or wrappers
> to make sure that your application will not be harmed by malicious/malfunctioning
> server (for example slow responder).
I've been using net/http in Go in four different companies. It is
production ready. httpc/httpd is an exercise in frustration. I would
actually prefer it was removed from Erlang/OTP so that the associated
modules do not occupate the global namespace.

At the end of the day, the answers here remind me of the Common Lisp
community. "Everything is fine, if you do not like it the problem is
you". After some time, people who get fed up leave, and the language
slowly dies.

-- 
Nicolas Martyanoff
http://snowsyn.net
khaelin@REDACTED