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

[Michael Malter]

It's fine. Let's try to keep a cool head.

I think your posts added to the general comprehension of the problem Austin.

I have also been guilty of being a little less diplomatic than usual here.
In the end, it's not a democracy but I have a feeling that most people are
against that eep. I have asked three of my friends. That's what I call
serious statistical sampling :)

Le lun. 25 avr. 2022 à 19:07, Austin Ziegler <halostatue@REDACTED> a
écrit :

> No, Stansilav, I’m an engineer. I’ve shipped software in ~35 different
> languages, which means that I aim to get ship done.
>
> If the only thing you can take away from my messages here is that I’m a
> "fanboy", then it is not my judgement in question.
>
> I will reiterate that this EEP was filed by someone who primarily writes
> in Erlang and wishes to see it in Erlang because they believe it would be
> beneficial in one of several different ways.
>
> The main objections that I have seen over the last two years on this have
> boiled down to:
>
> - It makes Erlang look like Elixir
> - It doesn’t add enough value
> - It’s a new sigil, and new sigils are by definition bad
>
> The first position, which is essentially what I have seen from you and
> several others, can be disregarded as emotional hyperbole. The second and
> third positions are worth discussing, but the level of emotion in the
> thread have resulted in little productive discussion on them.
>
> The first and third positions have ultimately precluded substantial
> discussion on the second and have discouraged possible explorations to see
> if the second position is, in fact, true. As I understand it, the Erlang
> compiler has changed pretty substantially in OTP23, OTP24, and OTP25
> (particularly with the introduction of the JIT in OTP24), which means that
> the introduction of a new sigil *might* permit the compiler to emit
> better (I’m being purposely vague here) code.
>
> The OTP implementation team thinks that it’s interesting and while they
> may not pick it up, they might. If they do, I hope that they look at Loïc’s
> suggestion, because I *am* of the opinion that adding a sigil should be a
> rare event, but adding a sigil that allows for greater future extensibility
> just *might* be worth it, even at the cost of a little bit of verbosity.
>
> In the end, you’re probably not going to listen and dismiss what I’ve said
> as fanboyism, but that doesn’t actually affect me.
>
> -a
>
> On Mon, Apr 25, 2022 at 12:43 PM Stanislav Ledenev <s.ledenev@REDACTED>
> wrote:
>
>> There were multiple arguments from a bunch of people.
>> The principle of the main one is "Render unto Caesar the things that are
>> Caesar's, and unto God the things that are God's".
>>  If you like Elixir no one objects on this. Just leave Erlang alone.
>>
>> But you just could not or don't want to listen.
>> Perhaps because you are a fanboy not an engineer if you can't see such
>> simple arguments.
>> And It's pointless to argue to argue with fanboys.
>>
>> пн, 25 апр. 2022 г. в 18:14, Austin Ziegler <halostatue@REDACTED>:
>>
>>> On Mon, Apr 25, 2022 at 10:58 AM Stanislav Ledenev <s.ledenev@REDACTED>
>>> wrote:
>>>
>>>> One question - why? Just because we can?
>>>> Erlang is doomed, Sorry Joe, we f**d things up.
>>>>
>>>
>>> I really can’t help but laugh at over the top reactions like this and
>>> those who can’t help but bash Elixir because they don’t like the syntax.
>>>
>>> What if this syntax (or some other syntax) helps the compiler generate
>>> better (safer, faster, *whatever*) code? How would anyone know unless
>>> it gets tried? Why would anyone want to try it when they know that a
>>> certain vocal subset of the community are going to be pitching embarrassing
>>> fits over it?
>>>
>>> If this is introduced in OTP 26, then stop upgrading. Seriously. Stay on
>>> OTP 25 or before. But seriously, stop acting like children about this and
>>> saying that things are fucked up (because they’re not; you just don’t like
>>> this because you don’t like it). The only *real* objection that I’ve
>>> seen that makes sense to me is from Loïc, which is that it might be better
>>> to enable *annotations*, even if the only annotation initially
>>> available is for pinning. (My personal feeling on the annotation concept is
>>> that `^pin Variable` doesn’t feel right to me, but maybe `^pin:Variable` or
>>> `^pin{Variable}` or `^{pin}Variable` or something else, although more
>>> sigil-y, would be clearer.
>>>
>>> I mostly use Elixir, but often read Erlang codebases. On the Elixir core
>>> mailing list, there are frequent redirects to approach something as a
>>> possible PR to Erlang/OTP because it’s something that should benefit all
>>> BEAM languages.
>>>
>>> Telemetry started as an Elixir library, but was quickly changed to a
>>> pure Erlang approach because it makes more sense to be something that all
>>> BEAM languages can use.
>>>
>>> Elixir has — and I suspect both LFE and Gleam both have — *enhanced *the
>>> BEAM through wider exposure, code contributions, and other contributions.
>>> If you can’t argue a feature request like in this EEP on its merits (or
>>> lack thereof) without trying to bash Elixir, then maybe you don’t actually
>>> have an argument, but an emotional outburst, and should just *discard* your
>>> rant after writing it.
>>>
>>> -a
>>> --
>>> Austin Ziegler • halostatue@REDACTED • austin@REDACTED
>>> http://www.halostatue.ca/ • http://twitter.com/halostatue
>>>
>>
>
> --
> Austin Ziegler • halostatue@REDACTED • austin@REDACTED
> http://www.halostatue.ca/ • http://twitter.com/halostatue
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20220425/e0c61346/attachment.htm>