move from json encoders/decoders to elm-serialize's codecs

[decioferreira]

Even though the dependencies and modules are not exactly the same, I leave here the comparison between space taken in comparison between elm, JSON encoders/decoders, elm-serialize codecs:

Elm:

% du -sh ~/.elm elm-stuff
4.0M    ~/.elm
6.8M    elm-stuff

JSON encoders/decoders:

% du -sh ~/.guida guida-stuff
8.0M    ~/.guida
 28M    guida-stuff

elm-serialize codecs:

% du -sh ~/.guida guida-stuff
4.9M    ~/.guida
 11M    guida-stuff

Regarding the time it takes to run the test suites, here are the values:

JSON encoders/decoders:

Test Suites: 1 passed, 1 total
Tests:       79 passed, 79 total
Snapshots:   0 total
Time:        55.147 s
Ran all test suites.

elm-serialize codecs:

Test Suites: 1 passed, 1 total
Tests:       79 passed, 79 total
Snapshots:   0 total
Time:        66.516 s
Ran all test suites.

[Warry]

This is extraordinary great work ! Congrats !

Out of curiosity, is it a goal to be exactly on par with ~/.elm ?

[decioferreira]

This is extraordinary great work ! Congrats !

@Warry Thank you! That means a lot! 😊 Glad you liked it!

Out of curiosity, is it a goal to be exactly on par with ~/.elm ?

At the moment that is not the intent, but I'm open to consider it if the right use case is presented. The initial implementation was done by using elm/json, which was the easiest option, and also it helped a lot when debugging the initial implementation. Now in this branch, we have 3 available options we could consider picking from: json, bytes and string. And on the package docs we can find the following:

You have three options when encoding data. You can represent the data either as json, bytes, or a string. Here's some advice when choosing:

If performance is important, use encodeToJson and decodeFromJson
If space efficiency is important, use encodeToBytes and decodeFromBytes*
encodeToString and decodeFromString are good for URL safe strings but otherwise one of the other choices is probably better.

Currently, we are focusing on performance. Let me know if this makes sense.

[Warry]

This is extraordinary great work ! Congrats !

@Warry Thank you! That means a lot! 😊 Glad you liked it!

Out of curiosity, is it a goal to be exactly on par with ~/.elm ?

At the moment that is not the intent, but I'm open to consider it if the right use case is presented.

No particular use case (I can use Elm to compile Elm), you've been very far in the immitation already ! It crossed my mind because I have written elmi and elmo decoder in the past (0.18 era), I know that it's quite annoying to debug. There have been tons of changes in 0.19.1 (UTF-8 in particular), and without the need for it anymore I didn't bother to port it.

The initial implementation was done by using elm/json, which was the easiest option, and also it helped a lot when debugging the initial implementation. Now in this branch, we have 3 available options we could consider picking from: json, bytes and string. And on the package docs we can find the following:

You have three options when encoding data. You can represent the data either as json, bytes, or a string. Here's some advice when choosing:
If performance is important, use encodeToJson and decodeFromJson
If space efficiency is important, use encodeToBytes and decodeFromBytes*
encodeToString and decodeFromString are good for URL safe strings but otherwise one of the other choices is probably better.

Currently, we are focusing on performance. Let me know if this makes sense.

I totally get it ! This is at most "nice to have". If it's not on your radar (well... because it's really peripheral), but you'd be open to pull request, I'd really like to at least figure out what's different, and see if there is a path moving forward.