Re: Support for non-unique process labels?

Stanislav Ledenev <[email protected]> writes:

>> As someone building a commercial project in Erlang, I can confirm that
>> doing anything production-ready in Erlang requires (re)writing a *ton*
>> of code which in other languages would be available in the standard
>> library. And do not even get me started on the tooling (or more
>> accurately lack thereof).
>
> Another claim without evidence. Why are you stating that Erlang
> "requires (re)writing a *ton* of code"? Maybe you love to rewrite tons of
> code?
> I have colleagues who love to refactor any working code, the love process
> not the result.
> Erlang is perfectly fine. It has everything you need to work to be
> done.

Of course, the calendar module is perfectly fine, even though it does
not support sub-second precision, does not handle timezone computations,
cannot parse/format arbitrary formats, and require constant conversion
from/to system time to do anything.

Of course string handling is perfectly fine, unless you need any kind of
unicode processing (good luck doing any kind of normalization to
propertly unaccent text, or any work with codepoint properties), or you
need to work with anything other than latin or utf8. And do not get me
started on the string/binary insany.

Of course math support is perfectly fine, until you need to handle NaN
or infinite values.

Of course httpc/httpd is perfectly fine. Right.

I could go on for a long time. Yes I can write libraries, this is what I
do. I.e. writing a ton of code.

You may have different needs, and it is fine. But the fact remains that
a lot of features which are basic necessities in 2021 are missing in
Erlang. I've seen lots of developers coming to Erlang, staring at the
lack of basic tools and functions, and going straight to Elixir (when it
is not another language altogether). I am pretty sure it is not a good
thing for Erlang.

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