Re: Support for non-unique process labels?

>
> 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 think you've chosen the wrong language for your needs then.
And your main claim is that Erlang is not _______ (place here any of your
favourite language).

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 glad that such newcomers don't stay with Erlang for long.
 For most of them programming languages differ only by syntax.
I've seen a lot of them in Elixir forums. And I've seen a lot of
conclusions like -
"gen_servers are evil because you can't write proper unit tests for them and
 therefore we must write less gen_servers" Yuck!
My only concern is that they trying to change Erlang to ______ (place here
any of your favourite language)


пн, 10 мая 2021 г. в 11:28, Nicolas Martyanoff <[email protected]>:

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