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

[Karl Velicka]

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/a8f00c58/attachment.htm>