<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I agree with this point. Less is more. <br>
    </p>
    <p>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.<br>
    </p>
    <p>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. </p>
    <p>On 2022-04-25 12:02, Stanislav Ledenev wrote:</p>
    <blockquote type="cite"
cite="mid:CAOkK=AKzPQmyyHh21WwN+9GiWZZRez+dyq8RA8-CRH7W-z-HNA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">I'll speak for myself.<br>
        <br>
        >> * Do people here genuinely feel that Erlang is in its
        global optimum <br>
        >> state right now and there are no positive improvements
        that can be<br>
        >> made?<br>
        <br>
        I think that Erlang as a language is quite close to its optimal
        <br>
        state: quite strict and simple (though powerful) syntax, <br>
        convenient modules concept, powerful OTP e.t.c.<br>
        Anything that I'll ever need can be implemented through
        libraries. <br>
        And the only language change which I'll be glad for is a native
        utf-8 string support.<br>
        Of course there are few libraries but it brings unneeded
        variations of implementations.<br>
        <br>
        >> * Do people here genuinely believe that Elixir is
        strictly a bad thing, <br>
        >> no positive things can come of it, and any ideas that
        in some way 
        <div>>> originate from Elixir is some kind of plague?<br>
          <br>
          I don't like Elixir because it is a category of syntactic
          sugar language which I <br>
          don't think is any good. But it is as it is and let it be. <br>
          What I hate most and this is very important is those changes
          to Erlang <br>
          rationalized by examples of the other language. <br>
          It is a road to hell. <br>
          For example, imagine what would happen if some ideas were
          brought to the Erlang <br>
          if we took some stuff from LFE(Lisp flavoured Erlang) to the
          core?<br>
          <br>
          >> * Lastly, there's a theme of taking potshots at C++.
          While it is true <br>
          >> that its evolution brought some bad things along with
          the good, I've <br>
          >> not heard a single C++ developer wishing that they
          could move <br>
          >> their codebase(s) back to an older C++ standard,
          which actually <br>
          >> happens to be entirely feasible in C++ ecosystem
          (some people/orgs run some _very_ old codebases, and as a
          result <br>
          >> ancient codebases are supported by newest versions of
          compilers). <br>
          >> So, how bad is the situation in "modern" C++ land
          really..? <br>
          >> (this last question is more rhetoric - I do not with
          to start a lengthy <br>
          >> discussion about merits of C++'s new additions in an
          Erlang mailing list)<br>
          <br>
          I strongly recommend to read this little paper of Bjarne
          Stroustrup<br>
          <a
            href="https://www.stroustrup.com/P0977-remember-the-vasa.pdf"
            moz-do-not-send="true" class="moz-txt-link-freetext">https://www.stroustrup.com/P0977-remember-the-vasa.pdf</a><br>
          <br>
          excerpt: "...so my reading of the Vasa story is: Work hard on
          a solid foundation, learn from<br>
          experience, and don’t scrimp on the testing.<br>
          <br>
          The foundation begun in C++11 is not yet complete, and C++17
          did little to make our<br>
          foundation more solid, regular, and complete. Instead, it
          added significant surface complexity<br>
          and increased the number of features people need to learn. C++
          could crumble under the<br>
          weight of these – mostly not quite fully-baked – proposals. We
          should not spend most of our time<br>
          creating increasingly complicated facilities for experts, such
          as ourselves."<br>
          <br>
          I mention C++ as an example of weird language evolution (?).
          C++ is evolving but<br>
          in a strange way. It's always becoming more and more complex,
          not the opposite.<br>
          If anyone writes C++ as it is he/she must write more and more
          code to solve<br>
          same old problems. As one of the examples - "Rule of three"
          became "Rule of five".<br>
          <br>
          At the same time there were so many languages which promoted
          themself as a "C++ killer" but C++ is still alive.<br>
          The problem with C++ - it kills itself. C++ is slowly dying. I
          can hardly<br>
          see any young software developers who wish to learn C++. They
          must learn so many<br>
          weird concepts to get so little. Even memory management with C
          is much easier<br>
          they can understand than this crap "rvalue"/"lvalue" stuff
          with copy, copy-assign, move etc.<br>
          <br>
          I'd be more sad if this happens with Erlang.<br>
          <br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">пн, 25 апр. 2022 г. в 12:16,
          Karl Velicka <<a href="mailto:karolis.velicka@gmail.com"
            moz-do-not-send="true" class="moz-txt-link-freetext">karolis.velicka@gmail.com</a>>:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div dir="ltr">
            <div>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.</div>
            <div><br>
            </div>
            <div>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: <br>
            </div>
            <div><br>
            </div>
            <div>* 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?<br>
            </div>
            <div>* 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?</div>
            <div>* 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)</div>
            <div><br>
            </div>
            <div>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..?</div>
            <div><br>
            </div>
            <div>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.</div>
            <div><br>
            </div>
            <div>I wish everyone all the best, and I hope  that this
              (and future) discussions could get a tiny bit less
              emotionally charged.</div>
            <div><br>
            </div>
            <div>Karl</div>
          </div>
          <br>
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">On Mon, 25 Apr 2022 at
              06:29, zxq9 <<a href="mailto:zxq9@zxq9.com"
                target="_blank" moz-do-not-send="true"
                class="moz-txt-link-freetext">zxq9@zxq9.com</a>>
              wrote:<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex"> From the EEP, which is
              about "pinning operators" (will the nonsense<br>
              cease?):<br>
               > In Erlang, they would be optional<br>
              <br>
              So why would you even want this? The entire idea is
              stupid, *implies* a<br>
              break with the basic rules already built into the
              language, and appears<br>
              to be nothing more than a way to roadmap the destruction
              of Erlang over<br>
              time with gee-whiz glyphy syntax of the sort which Erlang
              has been thus<br>
              far generally free.<br>
              <br>
              That's a big "NO" from me on this EEP, but I imagine
              anyone could have<br>
              already guessed that. Thanks for the heads up. I don't
              expect sanity to<br>
              prevail over time -- it is just the trend of the times --
              but it was<br>
              interesting to at least see this mentioned to those of us
              still<br>
              subscribed to the bad dirty old ML.<br>
              <br>
              -Craig<br>
              <br>
              On 2022/04/21 21:32, Leonard Boyce wrote:<br>
              > I'm copying the Erlang Questions ML with this post
              since there was<br>
              > significant and heated discussion regarding this EEP
              and not all ML<br>
              > subscribers have joined the forum.<br>
              > <br>
              > On Wed, Apr 20, 2022 at 10:20 PM Bryan Paxton via
              Erlang Forums<br>
              > <<a href="mailto:noreply@erlangforums.com"
                target="_blank" moz-do-not-send="true"
                class="moz-txt-link-freetext">noreply@erlangforums.com</a>>
              wrote:<br>
              >><br>
              >> starbelly EEF Board<br>
              >> April 21<br>
              >><br>
              >> EEP-0055 (<a
                href="https://github.com/erlang/eep/blob/master/eeps/eep-0055.md"
                rel="noreferrer" target="_blank" moz-do-not-send="true"
                class="moz-txt-link-freetext">https://github.com/erlang/eep/blob/master/eeps/eep-0055.md</a>)
              was submitted on<br>
              >> 21-Dec-2020.<br>
              >><br>
              >> An accompanying implementation (<a
                href="https://github.com/erlang/otp/pull/2951"
                rel="noreferrer" target="_blank" moz-do-not-send="true"
                class="moz-txt-link-freetext">https://github.com/erlang/otp/pull/2951</a>)
              was submitted in which a lot of conversation ensued.<br>
              >><br>
              >> 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.<br>
              >><br>
              >> That said, I wanted to start a topic here about
              the EEP and gun for inclusion in OTP-26.<br>
              >><br>
              >> I would point to @kennethL’s last comment (<a
                href="https://github.com/erlang/otp/pull/2951#issuecomment-770878570"
                rel="noreferrer" target="_blank" moz-do-not-send="true"
                class="moz-txt-link-freetext">https://github.com/erlang/otp/pull/2951#issuecomment-770878570</a>)
              on the PR as a starting point for discussion.<br>
              >><br>
              >> 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.<br>
              >><br>
              >> 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.<br>
              >><br>
              >> ________________________________<br>
              >><br>
              >> Visit Topic or reply to this email to respond.<br>
              >><br>
              >> You are receiving this because you enabled
              mailing list mode.<br>
              >><br>
              >> To unsubscribe from these emails, click here.<br>
              >><br>
              >><br>
            </blockquote>
          </div>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>