<div dir="ltr"><div dir="ltr">Den fre 22 jan. 2021 kl 12:57 skrev zxq9 <<a href="mailto:zxq9@zxq9.com">zxq9@zxq9.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Why is using Elixir not good enough? It already exists.<br></blockquote><div><br></div><div>Because there are companies with several million lines of Erlang code, and hundreds of Erlang developers (most of whom are not on this list). The code is not going to be rewritten in anything else. They need to keep their current developers happy enough not to leave for other jobs with languages that give them a better user experience, and they need to attract new people when others leave or teams grow - new people who have to get up to speed fairly quickly and not ragequit within a year. Fortran and C++ is no longer the competition. Rust, Go, Swift and TypeScript is. Even Java and to some extent Scala. Elixir has its own comfy niche in the Beam community where it's doing great stuff, but has not yet proved itself for the telecom-kind of large applications like at WhatsApp, Ericsson, Cisco and Klarna.</div><div><br></div><div><div>On a side note, I don't even know enough Elixir to write a whole program in it (not proud of that, just haven't had time - I still think of it as a kind of Ruby), and I wouldn't have known about their ^-annotation unless someone else had told me. To me it just seems like a pretty good solution.</div><div></div></div><div><br></div><div>I think Erlang needs to keep evolving, lest it becomes the Cobol of telecom and the only people on this list 10 years from now are the same people as today. We need to look honesly at where Erlang's ergonomics could be improved, and not hold on to the survivorship bias of our own "works for me and I've been doing it for decades" experience. The question we should be asking is how many people went out the door again because they felt other languages offered something better to them. Not change for change's sake, but change to reduce friction, churn and confusion, and to enable better tooling. Of course, safe, incremental change is the only way to do this.</div><div><br></div><div>It is clear that many people don't believe that ^-annotations are any good, so that might not happen. I can live with that. I can even live without warnings about already bound variables - I've done that for a long time. And if we go for only the warnings and no annotations, many people will be unhappy anyway because they may then be forced to use guards only (because of company coding standards, or if the open source thing they contribute to start enforcing the warnings for their code). It also becomes unlikely that it would be possible to backtrack and add ^-annotations later on, because by then everyone has turned their matches into guards already and won't go through the code to change it again, so the opportunity for an easy transition like the one I did on the OTP code base is lost.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Why not discuss eliminating shadowing entirely? Is there some reason <br>
this suggestion has not been addressed at all? It is a curious omission <br>
given that it has been brought up multiple times.<br></blockquote><div><br></div><div>I think this has been at least briefly discussed in some other branch of this thread - but it's a good point. We definitely know that there is some confusion there, particularly with shadowing of variables in list comprehensions (which work just like funs, for the generator patterns). For example, some people would write</div><div><br></div><div>    get_all(Id, List) -></div><div>        [X || {Id, X} <- List].</div><div><br></div><div>But Id is just as new as X in the pattern (you would get a warning for the outer Id being shadowed and the inner Id being unused, though). Similar mistakes can be made with funs, but people tend to have a better idea of how they work.</div><div><br></div><div>What would happen if we'd allow already-bound variables in these patterns? If someone uses shadowing today, it wil break their code, hard. I know it's not common to do this and to disable the warnings for shadowed variables but some people do it, and for them it would be a silent and breaking change. Maybe we can sacrifice them, maybe not.</div><div><br></div><div>The other thing would be that you could no longer move around a fun or list comprehension to a different location and expect it to keep working as before - and I think that particularly for funs, this is a fundamental assumption with most people, even if they don't use shadowing today. If you innocently cut and paste a simple "fun (X) -> X+1 end" or "[f(X) || X <- lists:seq(1,10)]" into another context, you have to be sure that X doesn't exist in that context, or your fun/comprehension will quietly start to try matching on that value instead. I think this would be too much for most people. Adding the warning about already bound variables would tell you this happened, at least, but you'd have to change the variable name just to get it to work again in the new location. My instinct is that this is something you don't want for funs.</div><div><br></div><div>    /Richard</div><div><br></div></div></div>