[Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055

Mon Apr 25 12:02:49 CEST 2022

I'll speak for myself.

>> * Do people here genuinely feel that Erlang is in its global optimum
>> state right now and there are no positive improvements that can be
>> made?

I think that Erlang as a language is quite close to its optimal
state: quite strict and simple (though powerful) syntax,
convenient modules concept, powerful OTP e.t.c.
Anything that I'll ever need can be implemented through libraries.
And the only language change which I'll be glad for is a native utf-8
string support.
Of course there are few libraries but it brings unneeded variations of
implementations.

>> * Do people here genuinely believe that Elixir is strictly a bad thing,
>> no positive things can come of it, and any ideas that in some way
>> originate from Elixir is some kind of plague?

I don't like Elixir because it is a category of syntactic sugar language
which I
don't think is any good. But it is as it is and let it be.
What I hate most and this is very important is those changes to Erlang
rationalized by examples of the other language.
It is a road to hell.
For example, imagine what would happen if some ideas were brought to the
Erlang
if we took some stuff from LFE(Lisp flavoured Erlang) to the core?

>> * Lastly, there's a theme of taking potshots at C++. While it is true
>> that its evolution brought some bad things along with the good, I've
>> not heard a single C++ developer wishing that they could move
>> their codebase(s) back to an older C++ standard, which actually
>> happens to be entirely feasible in C++ ecosystem (some people/orgs run
some _very_ old codebases, and as a result
>> ancient codebases are supported by newest versions of compilers).
>> So, how bad is the situation in "modern" C++ land really..?
>> (this last question is more rhetoric - I do not with to start a lengthy
>> discussion about merits of C++'s new additions in an Erlang mailing list)

I strongly recommend to read this little paper of Bjarne Stroustrup
https://www.stroustrup.com/P0977-remember-the-vasa.pdf

excerpt: "...so my reading of the Vasa story is: Work hard on a solid
foundation, learn from
experience, and don’t scrimp on the testing.

The foundation begun in C++11 is not yet complete, and C++17 did little to
make our
foundation more solid, regular, and complete. Instead, it added significant
surface complexity
and increased the number of features people need to learn. C++ could
crumble under the
weight of these – mostly not quite fully-baked – proposals. We should not
spend most of our time
creating increasingly complicated facilities for experts, such as
ourselves."

I mention C++ as an example of weird language evolution (?). C++ is
evolving but
in a strange way. It's always becoming more and more complex, not the
opposite.
If anyone writes C++ as it is he/she must write more and more code to solve
same old problems. As one of the examples - "Rule of three" became "Rule of
five".

At the same time there were so many languages which promoted themself as a
"C++ killer" but C++ is still alive.
The problem with C++ - it kills itself. C++ is slowly dying. I can hardly
see any young software developers who wish to learn C++. They must learn so
many
weird concepts to get so little. Even memory management with C is much
easier
they can understand than this crap "rvalue"/"lvalue" stuff with copy,
copy-assign, move etc.

I'd be more sad if this happens with Erlang.

пн, 25 апр. 2022 г. в 12:16, Karl Velicka <karolis.velicka@REDACTED>:

> Isn't that being at least a bit exaggerated/hyperbolic? Erlang has fairly
> glyphy <<"binaries">>, $c $h $a $r $s are also not entirely glyph-free, and
> neither are ?MACROS. Or the "send" operator (!), though it's not often used
> in production code in my experience.
>
> While I'm not massively for this particular EEP (I'd describe my position
> as ambivalent - I'd use it if it made it in, but I'll lose zero sleep if it
> doesn't), it feels like some people in this list (and this is most
> definitely not aimed at Craig in particular!) are laying the hyperbole on
> thick. A few key points appear to be "new == bad", "comes from elixir ==
> bad", "look at C++ and how terrible that is going". So, I'd like to raise
> some questions in response:
>
> * Do people here genuinely feel that Erlang is in its global optimum state
> right now and there are no positive improvements that can be made?
> * Do people here genuinely believe that Elixir is strictly a bad thing, no
> positive things can come of it, and any ideas that in some way originate
> from Elixir is some kind of plague?
> * Lastly, there's a theme of taking potshots at C++. While it is true that
> its evolution brought some bad things along with the good, I've not heard a
> single C++ developer wishing that they could move their codebase(s) back to
> an older C++ standard, which actually happens to be entirely feasible in
> C++ ecosystem (some people/orgs run some _very_ old codebases, and as a
> result ancient codebases are supported by newest versions of compilers).
> So, how bad is the situation in "modern" C++ land really..? (this last
> question is more rhetoric - I do not with to start a lengthy discussion
> about merits of C++'s new additions in an Erlang mailing list)
>
> There's also some suggestions of how Erlang _should_ evolve. Those include
> things that I also consider good ideas, but in some cases making them a
> reality can be tricky because one has to work out a  backwards
> compatibility strategy, provide some reference implementation etc.
> Criticising such work produced by others is on the other hand relatively
> easy. So I ask the proposers -  how are _you_ contributing to a more
> "Erlang-y"  future of the language? where are your EEPs? It's clear that
> some people in the community use Erlang extensively enough to face some
> issues with the language, and they're trying to make suggestions on how
> these might be improved. What we get from the mailing list community is a
> bunch of claims about how the proposers' problems are not real problems
> and/or their solutions are literally killing the language. So, my last
> question is - doesn't this kind of attitude have some elements of cutting
> the branch we (as the Erlang community) are sitting on..?
>
> I hope my questions didn't offend anyone (and particularly people whose
> points I referenced in my mail) - I've been a reader of the mailing list
> for many years and learned a lot from the regular posters here. However,
> there's been a few "incidents" over the years where some seemingly small
> things got blown completely out of proportion, and I think the community
> would be better off if its members firstly assumed overall positive intent
> (even though it might have downsides for some individual users), and took a
> few deep breaths before hitting "send", particularly in cases where typing
> up your response was a blood-pressure-raising activity.
>
> I wish everyone all the best, and I hope  that this (and future)
> discussions could get a tiny bit less emotionally charged.
>
> Karl
>
> On Mon, 25 Apr 2022 at 06:29, zxq9 <zxq9@REDACTED> wrote:
>
>>  From the EEP, which is about "pinning operators" (will the nonsense
>> cease?):
>>  > In Erlang, they would be optional
>>
>> So why would you even want this? The entire idea is stupid, *implies* a
>> break with the basic rules already built into the language, and appears
>> to be nothing more than a way to roadmap the destruction of Erlang over
>> time with gee-whiz glyphy syntax of the sort which Erlang has been thus
>> far generally free.
>>
>> That's a big "NO" from me on this EEP, but I imagine anyone could have
>> already guessed that. Thanks for the heads up. I don't expect sanity to
>> prevail over time -- it is just the trend of the times -- but it was
>> interesting to at least see this mentioned to those of us still
>> subscribed to the bad dirty old ML.
>>
>> -Craig
>>
>> On 2022/04/21 21:32, Leonard Boyce wrote:
>> > I'm copying the Erlang Questions ML with this post since there was
>> > significant and heated discussion regarding this EEP and not all ML
>> > subscribers have joined the forum.
>> >
>> > On Wed, Apr 20, 2022 at 10:20 PM Bryan Paxton via Erlang Forums
>> > <noreply@REDACTED> wrote:
>> >>
>> >> starbelly EEF Board
>> >> April 21
>> >>
>> >> EEP-0055 (https://github.com/erlang/eep/blob/master/eeps/eep-0055.md)
>> was submitted on
>> >> 21-Dec-2020.
>> >>
>> >> An accompanying implementation (
>> https://github.com/erlang/otp/pull/2951) was submitted in which a lot of
>> conversation ensued.
>> >>
>> >> It was decided that the EEP would not be set for inclusion in OTP-24,
>> per the time table at that juncture and that it would be revisited prior to
>> OTP-25. OTP-25 is now at a point where this is not possible.
>> >>
>> >> That said, I wanted to start a topic here about the EEP and gun for
>> inclusion in OTP-26.
>> >>
>> >> I would point to @kennethL’s last comment (
>> https://github.com/erlang/otp/pull/2951#issuecomment-770878570) on the
>> PR as a starting point for discussion.
>> >>
>> >> I suppose my overarching question here is : Is this still on the
>> table? And if so, what are the road blocks? Kenneth pointed out some
>> possible roadblacks that needed investigation, but it’s not clear to me
>> what happened after that.
>> >>
>> >> Of course, since I’m raising this topic, I’m obviously in favor of the
>> operator I’d also be happy to work to drive it forward.
>> >>
>> >> ________________________________
>> >>
>> >> Visit Topic or reply to this email to respond.
>> >>
>> >> You are receiving this because you enabled mailing list mode.
>> >>
>> >> To unsubscribe from these emails, click here.
>> >>
>> >>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20220425/d341a4c7/attachment.htm>