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