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

On 2022/04/25 18:16, Karl Velicka wrote:
> 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.

Escapes tend to require at least one reserved glyph. This is the tyranny
of ASCII creeping through. The point is to have as little of this as
possible and Erlang buys us quite a lot with the handful of instances
of glyph escapes that it does have. Adding an operator that is purely
optional but implies a semantic change is the opposite of "improvement"
and makes understanding code less simple.

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

It's ok, I'm a popular target. :-)

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

It is remarkably close to an optimum, yes. As a language, anyway.
Try designing a language, then stepping away from it for a year, then
come back and take a close look at it as an outsider.
It will very likely bother you.

Another language that is *very close* to optimum is Sophia.
Not perfect, but remarkably close to optimum, especially considering
its domain (smart contracts). I was so impressed with it that I would
consider making a "Sophia Flavored Erlang" if I happened to have
Elon Musk money. But I don't, so that's never going to happen.

Guile2 is also remarkably close to optimum, and similarly un-cool for
whatever reason. I don't pick what genpop finds cool and trendy, but I
can pick what I am going to use about 90% of the time, and Guile is
a really remarkable little language and runtime.

In Erlang probably the major change I would make is actually related to
shadowing and is something we even have a compiler warning about but is
not enforced: make *matches* in lambda argument lists occur rather than
*shadowing*. That is, don't add a pinning operator, just unify the
existing semantics of the language. Done. Simple. Now write code, not
ML posts about fever dream additions so Erlang can look more like
something else.

In the stdlib I might make a stdlib2 that standardizes things like
argument order and similar nitpicks, but this is really splitting
hairs and is *not* the language itself -- and can 100% be (and
should be IMO) an external project, so isn't even a language change.

I could say similar things about the type system and improvements
that could be made with a -pure declaration -- but this is also not
the core language itself.

Anyway, these amount to really minor nitpicks. Adding the pinning
operator would add *another* and much stronger area I would want to
simplify and clean up (a campaign to remove the pinning operator if
one existed would be higher in priority than the things I mentioned
above), so I'd rather not see it added in the first place. It would
be "let's make module namespaces into objects!" all over again.

Any larger and more disruptive change to Erlang would really be a
call for a different language, not a reasonable change to Erlang
itself.

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

No. I'm not a fan of Elixir, but if people like it, fine, use it. The
reasons I don't like it are why I like Erlang more, though, and I don't
want to see Erlang become Elixir by increments. That is the opposite of
having a meaningful diversity of available languages to drive the
runtime.

People who like Elixir use Elixir.
People who like Erlang use Erlang.
People who like LFE use LFE.
This is fine.

I really, really wish it were easier to support all of the BEAM
languages as purely peer languages (because then I could support
all of them in a single project under a single tooling umbrella)
but they aren't so whatever.

> * 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..?

I know C++ developers (especially in client-side game development) who
wish they could have kept C++11 forever, and some even previous versions
and quite a few who wish they could just stick with C *or* move to
something completely different than a C-based language entirely.

It is fascinating that reading and thinking carefully about the C++ FQA
is a better cognitive exercise than reading through the C++ FAQ.

> 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've given up on the part of the community that deliberately sought to
divide the community into people who follow the woke cult religious
dogma of ESG and DIE and enforce that division with a CoC. I have no
expectation that Erlang will hold together. This will be very sad, but
will not impair my ability to write useful software in whatever language
sucks the least at a given moment. Currently Erlang sucks the least for
most of the things I write, but that situation could change and likely
will as more garbage gets pumped into it.

My attitude about this is by no means unique, I am just in a position
professionally where I can actually say what I think out loud because
nobody can fire me for my beliefs -- a situation almost nobody in
the West enjoys at this point.

In fact, on this point, a member of my outcast community of math
and programming heretics wrote a few essays touching on this phenomenon
just the other day:

"Preference falsification:
Common sense in the back, compliance in the front"
https://zxq9.com/archives/2107

"Moral insecurity: why I’m racist"
https://zxq9.com/archives/2410

They are interesting essays and apply to the social problems that
are infecting and slowly (sometimes quickly) destroying almost every
open source community now (not to mention undermining faith in
public institutions and academia at a remarkable pace).

Anyway, the graybeard arguments against such changes as including
new stuff in the *language* that cannot be easily changed back rather
than focusing more effort on the runtime and libraries and tooling
is mostly in the spirit of delaying the eventual destruction of
Erlang's near-golden balance as a simple, small language.

Language design is *really* hard to get right and *very* easy to
screw up. There is a reason most of the old Pythonistas still
support, patch and write new code in 2.7 -- and also a reason that
Guido finally threw his hands up and quit in despair.

As for how are any of us trying to improve things... I've taken the
time to write a complete dynamic template/package/serve/build/launch
toolset for Erlang in Erlang, but just around the time I thought it
might be good to promote it people basically seem to have lost their
minds in ways that have nothing to do with the tech itself, so I'd
just rather not be bothered dealing with people who make a hobby of
taking indirect offense on behalf of people who themselves fail to
be sufficiently offended by whatever today's outrage is supposed to
be.

Why did I write tooling? Because that's the problem Erlang has.

Tooling.

Releases aren't the way and harsh responsibilities about dependency
management have to be assigned if you want a system where you can
simply type (as a user) `zx run [program name]` from anywhere that
has a network connection and have everything pull, build and run
in a sane way (that is, bring the ease of use of npm to Erlang but
without the insanity of npm dependency resolution).

Anyway, the main problem Erlang has is tooling and platform issues,
not language issues (and by "platform issues" I mean that I've already
solved the "first invocation means to pull and build" problem in a
cross-platform way, to the point you can write GUI apps that "just
work" anywhere, but still can't play sound or access audio/video
libs in a sane way that works cross platform -- if I could I would
probably eventually write game libs and VOIP clients in Erlang too).

The second problem Erlang has is the divided nature of the community,
which is why I tend to hang out with a handful of misfits, some of
whom must keep themselves anonymous for fear of reprisal for speaking
their mind. That's just how things are for now. Much like a stack of
other, similar situations in the world today, the problems are going
to get a whole lot worse before it gets better.

It is worth mentioning that there are no technical solutions for
social problems. Quite a lot of modern trouble exists due to a general
failure to understand how deeply this is true.

I hope everyone is having as pleasant a northern springtime as possible.

-Craig