[Erlang Forums] [Erlang/OTP Proposals/Proposals: RFC] Re-visiting EEP-0055
k32@REDACTED
k32@REDACTED
Mon Apr 25 14:00:16 CEST 2022
I agree with this point. Less is more.
So far, Erlang managed to keep most of its core features orthogonal.
Which helps adoption, since Erlang is a niche language with a
well-defined problem domain in mind: it makes implementation of
asynchronous and distributed systems easy and efficient. I'd had
experience mentoring fresh graduates and juniors in Erlang, most of them
were able to provide value to the product after three-four weeks of
learning Erlang.
No one is going to bother learning a complex feature-rich language for
just one domain. Currently Erlang is a nimble and efficient craftsman's
tool, not a Swiss knife. Keep complexity for "general-purpose" languages
that try to do everything, poorly.
On 2022-04-25 12:02, Stanislav Ledenev wrote:
> 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/802efb0e/attachment.htm>
More information about the erlang-questions
mailing list