Support for non-unique process labels?
Mon May 10 09:46:57 CEST 2021
On 10/05/2021 07:21, Nicolas Martyanoff wrote:
> Stanislav Ledenev <s.ledenev@REDACTED> 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.
More information about the erlang-questions