Re: Support for non-unique process labels?

Loïc Hoguin <[email protected]>
Newsgroups gmane.comp.lang.erlang.general
Organization Nine Nines
Message-ID <[email protected]>
On 10/05/2021 07:21, Nicolas Martyanoff wrote:
> Stanislav Ledenev <[email protected]> writes:
> 
>>>> When one of the main languages rolls their own in the stdlib, it is one
>> of many signals that adopting it in the core may be worth it.
>>>> At the same time, I understand that the OTP team may not want the
>> additional maintenance workload.
>>
>> Those claims without evidence look like manipulation.
> 
> 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).

You need to be accurate when making these statements. People have been 
greatly improving the standard library and the tooling for many years 
and it is unclear to me what parts would still be missing. So please 
indicate exactly what you had to rewrite or what tooling you are missing.

> It is not a deal breaker, I can work around it and accept it because the
> language itself is very good, but denying this reality is not
> productive. This situation actively damages Erlang adoption.

The obvious question is whether you can get your project done faster 
regardless of any inconveniences regarding the library or tooling. And I 
think that for more complex projects the answer is yes, you'll be done 
faster with Erlang. The pain point is only for more trivial projects. 
But again it would help knowing what is missing.

Cheers,

-- 
Loïc Hoguin
https://ninenines.eu
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.