[erlang-questions] No JSON/MAPS interoperability in 17.0?

[José Valim]

>
> I used the words bait-and-switch and I mean it there. This is one of the
> points where Jose Valim and I disagree the most.
>

Just to be clear: I was not advocating for bait-and-switch. I was not
advocating for optimizing "hello world".

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.

I know you know it, as you were the one who pointed it out. :)


> You start seeing node crashes because someone decided atoms is a good
> way to receive unvalidated data without first having implemented a
> scheme to GC them (say EEP-20:
> http://www.erlang.org/eeps/eep-0020.html).


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.

What we should focus on is explaining these tradeoffs and making it easy
> to show the different options. Currently, picking a JSON lib is hard
> because there is such a very poor match between what you can possibly
> encode in Erlang and how you can translate this back and forth with
> JSON. Not just because it's not in the standard library.
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140314/46bf42d7/attachment.htm>