Support for non-unique process labels?

[Loïc Hoguin]

On 10/05/2021 10:28, Nicolas Martyanoff wrote:
> Stanislav Ledenev <s.ledenev@REDACTED> 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.

Fair. This one would be a great project for anyone wanting to contribute 
to Erlang/OTP by the way.

> 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.

I don't think Erlang is too far off from many other languages here. I 
suppose we could make iconv part of the standard library, but it's 
already available in third party libraries, so it wouldn't be a huge 
difference. And let's be honest, converting from/to anything other than 
utf8 these days is becoming increasingly rare, especially in Erlang. I'd 
rather the focus be on supporting utf16/32 than supporting historical 
encodings, and leave those to external libraries.

Manipulation of Unicode strings is not quite there though. Sounds like 
another good contribution for anyone looking for something to do.

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

You're already aware of https://github.com/erlang/otp/pull/4537 - 
question is whether this will be accepted or not.

> Of course httpc/httpd is perfectly fine. Right.

It's useful to have a simple HTTP client built-in, on the other hand 
httpd could probably be dropped at some point. There's probably almost 
only historical users (possibly paying OTP team customers) at this 
point. And it's not super useful to have an HTTP server built-in.

I wouldn't expect a built-in HTTP client to shine in performance or 
anything though.

> 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 noted two. Please continue.

-- 
Loïc Hoguin
https://ninenines.eu