JSON library in Elixir core?

[José Valim]

Hello everyone,

I have heard that Erlang/OTP is not going to have a JSON library. That said, I think it would be very hand if Elixir fills in this gap and provide a JSON library in core. Does anyone have reasons for why Elixir should not support JSON out of the box?

PS: Please do not send pull requests for this yet as we will only worry about this after we have migrated to maps!

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Lead Developer

[ka...@kieliszczyk.net]

There is a third party library for using JSON in Erlang: https://github.com/talentdeficit/jsx
Do you think of writing Elixir own library or for example adopting this one?

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[José Valim]

We won't add dependencies to Elixir, so it would likely be an implementation written in Elixir.

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Lead Developer

[Dave Cottlehuber]

I'd love to see a built-in aka standard JSON parser in Elixir, as it
makes mixing and matching JSON internal formats across projects so
much easier. But I can understand the reasoning for why people decide
that it doesn't belong in core.

BTW there are in fact several JSON parsers already, many are
compatible licenses that could be brought into core if that is
appropriate.

Erlang:
https://github.com/talentdeficit/jsx
https://github.com/davisp/jiffy -- NIF-based
https://github.com/fishcakez/jixy -- wrapper to enable switching between them.

Elixir:
https://github.com/betawaffle/exon - in development
https://github.com/cblage/elixir-json
https://github.com/guedes/exjson
https://github.com/meh/jazz

And there are a few json querying modules too, such as:

https://github.com/etrepum/kvc
I don't think any yet support the new maps though.

A+
Dave

[Carsten Bormann]

On 08 Feb 2014, at 11:15, José Valim <jose....@plataformatec.com.br> wrote:

> Does anyone have reasons for why Elixir should not support JSON out of the box?

This isn’t a “yes", but let me point out some aspects of mapping between the JSON data model and what’s available a specific programming language can be application specific.

E.g., when I wrote excbor, I had to provide “treatments” to offer a number of different behaviors [sic] an application might want.

Now with maps firmly established, this should be simpler, (and JSON itself is simpler, too), but the issue of atoms vs. strings certainly needs to be addressed for the decoder. (And boring things, e.g., is 1.234e11 decoded as an integer or a float? Is -0.0 the same as 0.0?)
When encoding, there might be choices in pretty printing, a choice between using full UTF-8 or escaping everything non-ASCII in JSON strings, and possibly a desire to indicate the difference between string binaries and atoms. There also needs to be some decision how to handle non-textual byte strings (non-UTF8 Erlang binaries), e.g., croak on them.

The end result might be a standard library that has too many parameters and still doesn’t always do what an application wants.
(Or we might hit it exactly right. But that still needs to be shown. If we can pull that off, great.)

Grüße, Carsten

[Vincent Siliakus]

I have tried to think hard why the Erlang folks don't want to have a JSON library in Erlang's standard library and I *think* a reason to not include it is that different people have different expectations how and what native data types should be convertible to JSON (and vice versa, but to a lesser extend I think). Another reason could be that there are many other serialization/data-interchange formats out there that could be a better option than JSON, depending on the use case, so why not include protocol buffers, or thrift, or UBF, or etc. etc.?

That being said, I would love to see a JSON library in Elixir myself. It has (almost?) become the de facto standard for communication between servers and clients that speak HTTP. I use it regularly myself and I suspect a lot of other Elixir developers too. 

[Vincent Siliakus]

The end result might be a standard library that has too many parameters and still doesn’t always do what an application wants.
(Or we might hit it exactly right.  But that still needs to be shown.  If we can pull that off, great.)

I don't see any problems with having a relatively simple JSON library in Elixir that fits for the majority of use cases and still have third party JSON libraries for specialized/less common use cases. However, I'm not trying to imply that agreeing on what the majority of uses cases is will be easy :)

[meh.]

On Sat, Feb 08, 2014 at 11:15:34AM +0100, José Valim wrote:
> Hello everyone,
>
> I have heard that Erlang/OTP is not going to have a JSON library. That
> said, I think it would be very hand if Elixir fills in this gap and provide
> a JSON library in core. Does anyone have reasons for why Elixir should not
> support JSON out of the box?
>
> PS: Please do not send pull requests for this yet as we will only worry
> about this after we have migrated to maps!

One one hand I think this is best left in a third party library.

On the other hand having 3 different JSON libraries included in your
project because one dependency uses one, another uses another, and
you're using yet another almost sounds like a good enough reason to
include one in the stdlib.

And on yet another hand maybe jazz might be a good candidate once the
new map stuff is in and I update it to reflect the changes ( ≖‿≖)

[Johnny Winn]

Just my opinion but any JSON library should be outside of the standard lib. The standard lib should contain the basic building blocks for the language and then allow third parties to develop feature specific libraries. By incorporating JSON into standard lib you are essentially saying there is one way to handle JSON in Elixir. Plus, I think this gets away from the idea of small composable tools which is the backbone of functional languages.

The composition should be in the hands of the composer, not in the instruments :)    

[Kirill Romanov]

Elixir already has XML parsing library in stdlib, not speaking of distributed DB, so having JSON is not that bad.  

On the contrary I think that it's always a good thing to have a set of common serialization libraries always at your fingertips. 

Not sure if it plays well with the 'idea of small composable tools' and building blocks, but from purely practical point of view it's something developer can only dream about.

Last two weeks 10-15% of time I'm upgrading libraries to support new syntax. This got deprecated, that got deprecated etc, I've even managed to switch to eralng versions of certain libraries just to skip that deprecation hell for a while. Having lot's of tools in the stdlib would on the other hand make José care about those:) Moreover, having a lot of practical stuff in stdlib is an "erlang way".

суббота, 8 февраля 2014 г., 19:02:54 UTC+4 пользователь Johnny Winn написал:

[Jason Stiebs]

I'd say yes it it belongs in the standard library for many of the above arguments. 

[Paul Schoenfelder]

This feels like something best left out of the stdlib. JSON is used regularly enough that there will almost certainly be a solid third-party library readily available, and I would assume that as Elixir grows, the community will settle on one as the de facto standard. I do a lot of .NET programming for my day job, and the standard library JSON serializer is useless, I always use a third party serializer (JSON.Net), which is better in just about every way. I think that same situation is likely to apply equally well to Elixir's standard library - you are never going to get as robust a library baked in as you can out of a third party library: changes take longer to propagate, and instead of being a developer's primary focus, it ends up being yet another thing the language devs have to maintain. My vote is to keep it out of the standard library.

[Augie De Blieck Jr.]

From a purist's perspective, I agree. Keep all the extra modules as
external libraries. Besides, maybe JSON gets upended by some other
format next month and then we have this chunk of code in core that
nobody is using anymore and what's the point?

On the other hand, I'm more of a pragmatist. And if Elixir is going
to be used for web type stuff, having a built-in JSON parser would be
a big help. For someone just starting Elixir, it'll make for a
simpler transition to the language. There will still be other
libraries out there to choose from if they offer a feature you'd
rather have, but otherwise getting one built in is a huge help. Keeps
your list of dependencies smaller. it's not the perfect
implementation of small focused things being chained together anymore,
but those things are exceedingly rare, anyway.

The best argument against it, to me, is the one Paul just mentioned.
A JSON parser will be necessary, someone will create the best one, and
everyone will end up using it. Let someone else do that work and THEN
fold it into core. ;-)

-Augie

[William Oliveira]

I agree with Augie, it would be really handy having a JSON lib built-in for web development.

Not only for that, would be really useful for many purposes. I like the idea. :-)

--
// w. oliveira 

// js - python - lisp - clojure

[Johnny Winn]

I think the points both Paul & Augie make are good examples of not including it in standard lib. The core team would be responsible for managing code that could be easily managed by third parties. Another point to note is that we keep saying that it would be convenient for web development. Web development is one specific use case where standard lib implies base functionality to build on. As far as standard lib supporting XML, I would argue that it needs to be extracted rather than become a precedent for additional serializers.

This is also a case where something like the beam-toolbox would be a great solution to introduce new devs to libraries by use case. 

All that being said, they are just my opinions and I may be off base in my interpretations. 

[Saša Jurić]

I'm also against including json in Elixir stdlibs. While this is often used, it doesn't feel as all-purpose tool. Such introductions to stdlib might lead to an overbloated Elixir core. As has been pointed out, the question is why just json? Why not protobufs, or proper xml support? While we're at it, why not include a web framework to simplify the "web stuff" that has been mentioned?

All that said, I don't like the fact that already we have a couple of json libs, and I'm not even sure which one should be used. So maybe it would be a good idea for Elixir to "promote" recommended lib, perhaps by introducing elixir-lang/json repo. Going beyond, maybe it would be useful to provide a broader set of libs in a single elixir-lang/framework repo. This makes it possible for Elixir to offer preferred libs for some common problems, while retaining a simple core.

[Yurii Rashkovskii]

I also don't think that having a JSON library in Elixir stdlib is a good idea. There has been a lot of conversations about how great would it be if Erlang stdlib wasn't such a bloat — just a minimal core and the rest would be third party libraries with its respective maintainers. 

Here is my list of "why no"s:

* It is a focus/time drain for elixir maintainers

* It'll likely never get as good as it can be (I had a chance to talk to jsx/jsex author, writing a JSON library is no trivial feat)

* Many languages don't have it standard or if they do, almost nobody uses that option

* It is a slippery slope — why not include protobufs, msgpack, etc? Those are also fairly common 

[Carsten Bormann]

Happily contradicting myself, there is also something to be said for a “batteries included” approach.

JSON is so central to many kinds of communication these days that making users search for an implementation qualifies as not including batteries.
(Many of Elixir’s “batteries” come with the easy availability of Erlang’s library from Elixir. Now if there is no JSON there…)

> Here is my list of "why no"s:
>
> * It is a focus/time drain for elixir maintainers

Actually, it might focus the view of the Elixir language designers on the fact that it is a good idea to have good impedance matching to the JSON world.

(A more important point is making sure the library can still evolve. But with the rapid speed that Elixir itself evolves, I don’t see a danger of ossification.)

> * It'll likely never get as good as it can be (I had a chance to talk to jsx/jsex author, writing a JSON library is no trivial feat)

Indeed. But maybe one of the maintainers there actually is interested in supplying a cleaned up standard library version?

> * Many languages don't have it standard or if they do, almost nobody uses that option

Elixir might want to be better than that...

> * It is a slippery slope — why not include protobufs, msgpack, etc? Those are also fairly common

You forgot CBOR :-).
None of these has the standing and the immediate relevance of JSON.

Grüße, Carsten

[meh.]

Personally I see the elixir-lang/json and possibly other "batteries
included" libraries under the elixir-lang tree would be a better
choice for certain things.

Instead of including it in the current way the stdlib is handled,
which I personally don't like at all.

Sincerely I think the elixir repository should only include Elixir. So
if it were up to me, I'd move eex, ex_unit, iex and mix outside of
elixir repo, and that'd open up a better way to maintain the
"batteries".

But I guess this isn't the right thread for this kind of discussion.

On Sat, Feb 08, 2014 at 09:49:02PM +0100, Carsten Bormann wrote:
> Happily contradicting myself, there is also something to be said for a "batteries included" approach.
>
> JSON is so central to many kinds of communication these days that making users search for an implementation qualifies as not including batteries.

> (Many of Elixir's "batteries" come with the easy availability of Erlang's library from Elixir. Now if there is no JSON there...)

>
> > Here is my list of "why no"s:
> >
> > * It is a focus/time drain for elixir maintainers
>
> Actually, it might focus the view of the Elixir language designers on the fact that it is a good idea to have good impedance matching to the JSON world.
>
> (A more important point is making sure the library can still evolve. But with the rapid speed that Elixir itself evolves, I don't see a danger of ossification.)
>
> > * It'll likely never get as good as it can be (I had a chance to talk to jsx/jsex author, writing a JSON library is no trivial feat)
>
> Indeed. But maybe one of the maintainers there actually is interested in supplying a cleaned up standard library version?
>
> > * Many languages don't have it standard or if they do, almost nobody uses that option
>
> Elixir might want to be better than that...
>

> > * It is a slippery slope -- why not include protobufs, msgpack, etc? Those are also fairly common

>
> You forgot CBOR :-).
> None of these has the standing and the immediate relevance of JSON.
>
> Grüße, Carsten
>

[Augie De Blieck Jr.]

OK, I think Johnny has changed my mind. There's enough on the plate
of the language's core team to worry about without throwing them
another module to deal with. While you could probably bring in a
pre-existing module and have its creators come along with it to work
on it, it's still extra work in coordination. Right now, there's
enough going on. Let's get 1.0 out the door before adding these bells,
whistles, or batteries. Maybe if Elixir evolves in such a direction
that JSON becomes a crucial part of using it in so many examples,
it'll be worth bringing something in later down the road. (See? Still
pragmatic. I leave the door open if its most useful and not
detrimental.)

So while maybe not for all of the same reasons, I'm inclined to change
my "vote" (as if I had one) to leave that out and use an external
library for JSON purposes right now.

-Augie

[Devin Torres]

Adding functionality like a JSON module isn't a zero-sum game, because individuals like meh and myself would be contributing to it and not taking time/energy away from other areas of Elixir. In fact, I've already written much of a potential parser (that's been benchmarked to be faster than jiffy) and have been waiting for maps to land to finish an encoder I've been working on.

The batteries included aspect of Python is regularly heralded as something very positive by newcomers to the language. I don't agree with the slippery slope fallacy that adding JSON -- a feature that's been oft requested in both Erlang and Elixir (as evidenced by the plethora of libraries in each language seeking to become the de-facto implementation) -- is going to lead us to some crazy dilemma where we're wondering whether to include protobufs in core. JSON is such a pervasive data-interchange format -- now famously even ECMA standardized (which is a whopping 5 pages, by the way) -- that there's no excuse for us to not have a JSON module in core.

Every other Elixir project on Github includes one of four of five JSON implementations when 99% of projects simply need simple JSON encoding/decoding, at times forcing me to forgo using a library simply because it would add a second or third JSON dependency that I really would rather avoid. Adding a simple JSON protocol in core will allow the 99% to use the JSON protocol in their projects with the expectation that everyone can use it, instantly giving us the ability to define JSON serialization/deserialization on the things we use in our libraries. People that need application specific features like SAX style parsing (which, if Github is any indication, nobody actually uses) then they are free to forgo the standard JSON module and include theirs as a dependency.

-Devin

[Peter Minten]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/02/14 22:40, meh. wrote:
> Personally I see the elixir-lang/json and possibly other "batteries
> included" libraries under the elixir-lang tree would be a better
> choice for certain things.
>
> Instead of including it in the current way the stdlib is handled,
> which I personally don't like at all.
>
> Sincerely I think the elixir repository should only include
> Elixir. So if it were up to me, I'd move eex, ex_unit, iex and mix
> outside of elixir repo, and that'd open up a better way to maintain
> the "batteries".
>
> But I guess this isn't the right thread for this kind of
> discussion.

I've been thinking along the same lines sometimes. Perhaps it's useful
to consider dependencies. If you look at what's currently in the
Elixir main repo there are really these things:

1. The Erlang code of the core Elixir implementation and Elixir code
that is used by the Erlang code.
2. Core Elixir libraries that are very strongly tied to the
implementation (stuff like Module, Kernel.Typespec).
3. Very basic standard library functions (Enum, String).
4. Non-basic standard library functions (Regex, URI).
5. Mix, build tool. Used by the core implementation.
6. IEx, nice interpreter.
7. ExUnit, testing tool. Used by the core implementation.
8. EEx, output formatting tool. Used by mix.

I've been wondering if it would be possible to create "rings" of
libraries where libraries in one ring only depend on libraries in the
same ring or lower. But unfortunately it doesn't seem to be possible
to do this, only IEx could be separated out but the value of that
would be dubious.

On the other hand it is a valid question what the policy for including
something in the standard library is. Consider that things like
Char.isalpha predicates are considered not suitable for the standard
library, which would indicate a desire to keep the standard library
minimal.

In my mind it doesn't really matter all that much whether JSON or any
specific module gets added to the standard library. What matters most
is that there is a clear policy on how expansive the standard library
should be.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS91ihAAoJEP1SBN68kfQvCLEP+wZEXSVk09/vu0J1slZXxk0K
MmerPUM/WHRBICOInTQtFkMexbN5YUwS4L5IsdqW1NgCpVqYs1plkB6qqhJlZdg8
lnvLKalVM2Rhyx9M61S+NzW+UCgvmfJQgEh77hg1DeNVRendoiDXNTSzrfIic5no
LqQCWai8EYo3NE1+zrsWqLs4qCcr8ybxaLmlMu4wSM1+ZvjJ3THoCtDtXmonbOZG
ZMpANes/lDoIinzWzCdTkLtgrI7kMNDPDD/T0yf2yWJ56zcoU+OG+AlW20YnYPFO
zeL10twGzTD8vo/GG0bEU+s5kuAucAHjgUiJaObAacOB3exsfwAkJ1qtm7Qiccxv
b8H2MEBiAcf2G+4LhmsDkutw5RD4NbkcBYpoyZ3EE96LJx9dbmoPj6DPjp9aWU3M
l/IC1ma1PM4VK1JLXBkG50d63WPnOO5Qil10OFGVqkFcLahtImGwRyALUuZFqiAq
InTMwr1wOd8AtJaxwwRF8scsRFcYZZiuAtCB8yAHGIB5qaNDjr1qRwZRHoHwZxMf
JRKgTTrksZbhvOQZf4Y/d+JxuUpWr45qS0KZ8g0r2kVmFwuQx37fIoFGEmRFD66B
ZuW5KkMua2PyDUP2ILJVc7FEHlc6wVCvf5pdPwDr6FfeAomSsy5OUn6pgYNydsnY
e6N37da6bE0SW0uWPj8Z
=NlIo
-----END PGP SIGNATURE-----

[Yvan Godin]

+1 for JSON
we already have XML and URI.
JSON will be also great also because it is mainly used in HTTP land and notably for REST protocol.
JSON will become a part of next upcoming Javascript.
A language can't win alone, it need bateries and even Erlang have some (xml, Wx ...).

just my point
Yvan

[José Valim]

There is no XML in Elixir. URI is a very tiny module compared to anything like JSON. :)

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Lead Developer

--

[o...@aleph0.cc]

:xmerl :) the truth is that it's available...

воскресенье, 9 февраля 2014 г. пользователь José Valim написал:

[mrshankly]

On 09/02/14 11:40, o...@aleph0.cc wrote:

:xmerl :) the truth is that it's available...

воскресенье, 9 февраля 2014 г. пользователь José Valim написал:

There is no XML in Elixir. URI is a very tiny module compared to anything like JSON. :)

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Lead Developer

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

xmerl is not elixir thought.

[Josh Adams]

Alright, I was coming here to ask where Elixir had XML, because if it had it I was going to feel like a dope doing a series on using xmerl, but yeah, that's what I thought.

Having :xmerl is clearly not the same as having XML built-in.  Importing records to do anything useful == not first-class in elixir (status in Erlang proper be damned).

I was going to proffer a -1 on this feature earlier, at least for 1.0.  I'm not sure where I stand now.  I know that I think it's a +1 after 1.0, and if including it isn't going to detract from the rest of the language's development, then I think I'm +1 on it for now.  Primarily for the 'zomg so many json dependencies' reason.

Having json built in isn't going to detract from the chance to use external json libs when needed for some reason, as evidence I offer Ruby.  Anyway, that's my take on it - cautionary +1 for pre-1.0, blatant +1 for post-1.0.

Josh Adams

[Kirill Romanov]

Yes, sure it's not. But still it's the one of many reasons to use it (Elixir). Another reason, is :erlang.spawn_link, :ets, :mnesia etc. Don't get me wrong, Elixir itself is a great language on it's own right. Metaprogramming stuff is just great, I've never used such an expressive language before(I can speak for hours how great Elixir is), but runtime and ecosystem available is the corner stone for me as I'm solving purely practical problems.

Now I have, I think ~10 Elixir production projects, running on clusters of various size. Honestly, I think I'm the most active user of Elixir to date in terms if CPU hours/ day:) And all of those pieces of software are using JSON. So, do I want it to be a part of stdlib? Yes, definitely. Can I live without it? Sure, as seen from the practice. 

On the other hand, I'm quite interested in Elixir's bright future. And comparing it to rise of node.js I can say having web server in stdlib, having JSON in stdlib is a good idea, as it attracts newcomers.

воскресенье, 9 февраля 2014 г., 19:29:56 UTC+4 пользователь Josh Adams написал:

Alright, I was coming here to ask where Elixir had XML, because if it had it I was going to feel like a dope doing a series on using xmerl, but yeah, that's what I thought.

Having :xmerl is clearly not the same as having XML built-in.  Importing records to do anything useful == not first-class in elixir (status in Erlang proper be damned).

I was going to proffer a -1 on this feature earlier, at least for 1.0.  I'm not sure where I stand now.  I know that I think it's a +1 after 1.0, and if including it isn't going to detract from the rest of the language's development, then I think I'm +1 on it for now.  Primarily for the 'zomg so many json dependencies' reason.

Having json built in isn't going to detract from the chance to use external json libs when needed for some reason, as evidence I offer Ruby.  Anyway, that's my take on it - cautionary +1 for pre-1.0, blatant +1 for post-1.0.

On Sun, Feb 9, 2014 at 6:15 AM, mrshankly <mrshank...@gmail.com> wrote:

On 09/02/14 11:40, o...@aleph0.cc wrote:

:xmerl :) the truth is that it's available...

воскресенье, 9 февраля 2014 г. пользователь José Valim написал:

There is no XML in Elixir. URI is a very tiny module compared to anything like JSON. :)

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Lead Developer

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

xmerl is not elixir thought.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Josh Adams

[Josh Adams]

I did not mean to come off as saying that using Erlang libraries from Elixir is somehow bad form - just that 'Elixir has XML built in' is kind of wrong.  Also, using xmerl is explicitly more awkard than using most Erlang libs, because of the record imports at the very least.

<3 Erlang libs, and using anything that runs on the BEAM is feature #1 in Elixir's usefulness / adoption-worthiness at this point, easily.

[José Valim]

The main reason for bundling JSON in core is to unify all usage out there. That said, I believe that providing an elixir-lang/json library is a great suggestion. The question is: would it be enough to unify the ecosystem? At least, could it be the go to library for the majority of use cases?

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Lead Developer

[Sasa Juric]

Another reason for having separate Elixir and json lib is that they can evolve separately.

Let’s say json is a part of stdlib and some json bug/defect must be fixed. Now we have to release a new Elixir version just to address the json problem. Similarly, when a new Elixir version is about to be released, all pulled changes from json lib will be bundled with the new release.

If they are maintained separately developers have more freedom in choosing a combination they prefer.

Again, I’m all for having elixir-lang promoted libs, just like the case is with ecto. If there are 10 json libs, and one of them is under elixir-lang repository, I’d use that one by default, resorting to others if elixir-lang doesn’t cut it.

[Josh Adams]

I like the reasoning here.  So much internal struggle!

--
Josh Adams

[Devin Torres]

Also, I think a pot of people here are overestimating how large a JSON "library" would be. A couple of files a library does not make. Ecto clearly doesn't belong in core, but something as simple and useful as JSON does.

[Gilbert Kennen]

On 02/09/2014 07:42 AM, José Valim wrote:
> The main reason for bundling JSON in core is to unify all usage out there.
> That said, I believe that providing an elixir-lang/json library is a great
> suggestion. The question is: would it be enough to unify the ecosystem? At
> least, could it be the go to library for the majority of use cases?

Is fragmentation such a problem that we need to include this in the
standard library?

Including JSON sends a branding message about Elixir that it is going to
especially support web developers. Many of the web-oriented folks are
likely going to think it is a good idea because it is one less thing for
them to think about when putting together a web application and it makes
the ecosystem a bit more accessible and marketable for people in their
communities. On the other hand, Elixir already has a bit of a reputation
(deserved or not) of aspiring to be Ruby and Rails on Erlang and little
decisions like this only reinforce the reputation.

Personally, I don't think it adds much to the core language to have JSON
there. The use-cases where JSON is needed, but the developer doesn't
need to go find other things which are completely inappropriate for
standard library inclusion seem rather rare. We actually need better
communication tools (as have been recently discussed on the talk list)
so that when you need JSON, you can understand your options and choose
the right implementation.

If anything, I would prefer to see the proposed JSON implementation
initially developed as a separate library since its functionality isn't
proposed to be core to anything Elixir does and that separation would
allow it to develop without impeding or being impeded by Elixir
development. We can then see if the implementation feels like a good,
lasting fit for the language. It's easy for a lot of people to say
'yeah, I like JSON', but might be different for people to say 'yeah, I
like that JSON implementation' and without widespread support for an
implementation, people will just ignore the default and fragmentation
will still occur.

[Devin Torres]

A huge reason this belongs on core is not having it would rule out an entire class of tooling that uses the web. For example, I toyed with the idea of writing mix tasks to automatically resolve and set up component.js dependencies in a project, something that would be impossible today without FIRST pulling down Elixir dependencies and compiling. It just seems so ridiculous to need a dependency to talk the format 99% of modern web APIs export today.

[Tallak Tveide]

Hi. I like the Rails model here: some dependencies are added by default, but they might be deprecated in future versions. If that happens you should rewrite your code or include the library explicitly.

So what I suggest is: the Elixir team adds some useful libs in a standard package that is installed along with Elixir. These may be used without specifying anything in the mix file. But they are not part of Elixir core and may be replaced in the future. Newer versions of any of these libs may be specified explicitly if necessary in the mix file.

[José Valim]

I am afraid this solution brings the downsides of both sides and but none of the upsides. The community won't have a solution they can rely on (since it may be replaced) and we will still have the burden of maintaining or being responsible (to some extent) by the bundled libraries.

People expect languages to be stable for years. Actually, people expect that from frameworks as well, but Rails is known for moving fast (and if it is a good or bad thing, it is up to you).

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Lead Developer

On Sun, Feb 9, 2014 at 8:41 PM, Tallak Tveide <tal...@gmail.com> wrote:

Hi. I like the Rails model here: some dependencies are added by default, but they might be deprecated in future versions. If that happens you should rewrite your code or include the library explicitly.

So what I suggest is: the Elixir team adds some useful libs in a standard package that is installed along with Elixir. These may be used without specifying anything in the mix file. But they are not part of Elixir core and may be replaced in the future. Newer versions of any of these libs may be specified explicitly if necessary in the mix file.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

[Jim Freeze]

The JSON standard, or at least the implementations, seem to be changing frequently.

Does anything go into the std lib that changes frequently?

On Sat, Feb 8, 2014 at 8:23 AM, meh. <m...@schizofreni.co> wrote:

On Sat, Feb 08, 2014 at 11:15:34AM +0100, José Valim wrote:

> Hello everyone,
>
> I have heard that Erlang/OTP is not going to have a JSON library. That
> said, I think it would be very hand if Elixir fills in this gap and provide
> a JSON library in core. Does anyone have reasons for why Elixir should not
> support JSON out of the box?
>
> PS: Please do not send pull requests for this yet as we will only worry
> about this after we have migrated to maps!

One one hand I think this is best left in a third party library.

On the other hand having 3 different JSON libraries included in your
project because one dependency uses one, another uses another, and
you're using yet another almost sounds like a good enough reason to
include one in the stdlib.

And on yet another hand maybe jazz might be a good candidate once the
new map stuff is in and I update it to reflect the changes ( ≖‿≖)

--
Jim Freeze

[Carsten Bormann]

On 10 Feb 2014, at 01:05, Jim Freeze <jimf...@gmail.com> wrote:

> The JSON standard, or at least the implementations, seem to be changing frequently.

No.

JSON has been described by the stable RFC 4627 since July 2006 (and that only documented stable practice).
Recently ECMA have created a little bit of instability by allowing other data than maps (objects) and arrays at the top.
This relatively trivial change will be reflected in a new RFC, currently at draft stage at:
http://tools.ietf.org/html/draft-ietf-json-rfc4627bis

Nothing else of substance has ever changed in JSON.

Now, of course, implementations can be improved all the time.
Some, misguidedly, compete in accepting any kind of soup that calls itself JSON (adding comments, single quotes, bad Unicode, …).
Don’t do that.

More importantly, libraries may improve in the way they map the simple JSON data model to and from the programming language’s data model.
This is a place where the history of Elixir actually makes me hope its implementation will excel.

Grüße, Carsten

[Stuart Coyle]

It would be interesting to see how many different JSON libraries are actually used.

I suspect that most of us who use JSON are using jsx.

If there is already a consensus library being used I see no point in adding one to Elixir. If there is a Babel of incompatible

libraries being used then maybe adding one to std lib will be of value so that we can be sure of how our JSON is being 

parsed and generated.

On Mon, Feb 10, 2014 at 11:13 AM, Carsten Bormann <cabo...@gmail.com> wrote:

On 10 Feb 2014, at 01:05, Jim Freeze <jimf...@gmail.com> wrote:

> The JSON standard, or at least the implementations, seem to be changing frequently.

No.

JSON has been described by the stable RFC 4627 since July 2006 (and that only documented stable practice).
Recently ECMA have created a little bit of instability by allowing other data than maps (objects) and arrays at the top.
This relatively trivial change will be reflected in a new RFC, currently at draft stage at:
http://tools.ietf.org/html/draft-ietf-json-rfc4627bis

Nothing else of substance has ever changed in JSON.

Now, of course, implementations can be improved all the time.

Some, misguidedly, compete in accepting any kind of soup that calls itself JSON (adding comments, single quotes, bad Unicode, ...).

Don't do that.

More importantly, libraries may improve in the way they map the simple JSON data model to and from the programming language's data model.
This is a place where the history of Elixir actually makes me hope its implementation will excel.

Grüße, Carsten

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Stuart Coyle
stuart dot coyle at gmail dot com

[Josh Adams]

I use jazz and <3 it

Josh Adams

[Yvan Godin]

I use elixir-json
Yvan

[Jim McCoy]

One question I see not being asked, or at least answered quite poorly, is "what problem is this solving?"  Having to choose one from among X JSON libraries for your project or to add as a dependency is not really a problem, and definitely not one that needs to be solved in the core of the language.  Needing to talk to a web api is not a problem that needs to be solved in the core of the language; if you spend your time writing web sites it might seem like this is the most important thing in the world, but as someone who spends time building infrastructure tools and is more often diving down to the packets than climbing up to templates and stylesheets I think it would be quite a shame if this cool little language let itself be defined so quickly around such a limited vision of what it could possibly do and become. If, over time, there is one library that stands above the others as the one true way to accomplish a task that everyone is doing then it will become an obvious choice for inclusion in the standard library; this is clearly not the case with JSON right now.

If the core language and standard libraries cannot be implemented and released/distributed independently then it seems prudent to keep the core of the language as small and clean as possible.

[Carsten Bormann]

On 10 Feb 2014, at 12:33, Jim McCoy <jim....@gmail.com> wrote:

> If, over time, there is one library that stands above the others as the one true way to accomplish a task that everyone is doing then it will become an obvious choice for inclusion in the standard library; this is clearly not the case with JSON right now.

There is a difference between throwing together a JSON library and designing one that is fit for adoption as a part of the Elixir standard library.
If José says the latter will never happen, that design will not happen either.

So instead of continuing to discuss whether there should be one in the standard library, I’d rather have us discuss what its properties should be.
That discussion (and whether it has an outcome at all) should inform the former decision.

Grüße, Carsten