<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I used the words bait-and-switch and I mean it there. This is one of the<br>


points where Jose Valim and I disagree the most.<br></blockquote><div><br></div><div>Just to be clear: I was not advocating for bait-and-switch. I was not advocating for optimizing "hello world".</div><div><br>

</div><div>I was/am advocating for providing "higher level abstractions" that are first proved to be useful in production. A direct consequence of having those is that it would provide more palpable abstractions for those getting started with the language. Point in case: one of the patterns proposed (the task pattern) *already* exists in OTP and is used in the OTP codebase itself. It is not an invention nor a bait-and-switch mechanism.</div>

<div><br></div><div>I know you know it, as you were the one who pointed it out. :)</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You start seeing node crashes because someone decided atoms is a good<br>
way to receive unvalidated data without first having implemented a<br>
scheme to GC them (say EEP-20:<br>
<a href="http://www.erlang.org/eeps/eep-0020.html" target="_blank">http://www.erlang.org/eeps/eep-0020.html</a>). </blockquote><div><br></div><div>This is happening not because a 70% solution was provided but because a very bad design decision was made i.e. using atoms for decoding unverified data by default. A 99% solution, whatever that would mean, would still be a horrible solution if that is the default behaviour.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What we should focus on is explaining these tradeoffs and making it easy<br>
to show the different options. Currently, picking a JSON lib is hard<br>
because there is such a very poor match between what you can possibly<br>
encode in Erlang and how you can translate this back and forth with<br>
JSON. Not just because it's not in the standard library.<br></blockquote><div><br></div><div>It should be clear to everyone that providing a built-in solution does not mean "we never get to talk about it, ever again". In fact, this is something the OTP documentation in general does pretty well: making it clear (with the green and red boxes) when something in particular must be used or avoided.</div>

<div><br></div><div>Personally, I am against including JSON by default too. But arguing the reason to not include it is because someone can make a bad design decision or because it will automatically stop all discussion around the other solutions seems to be a very weak point against it.</div>

<div><br></div></div></div></div>