You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The plan right now is to make a proposal for the Elixir standard library to include an Elixir wrapper around json with encoder protocol and interface more similar to Jason that's easy to use from Elixir.
When this is integrated the Jason library itself would become deprecated.
The plan right now is to make a proposal for the Elixir standard library to include an Elixir wrapper around json with encoder protocol and interface more similar to Jason that's easy to use from Elixir.
When this is integrated the Jason library itself would become deprecated.
That approach makes sense long term. In the shorter term, does the approach above imply that there will be at least a 6-month window—until, say, Elixir 1.18—and possibly a 2-year window, until Elixir requires OTP 27+—in which there will be no drop-in solution for leveraging the new json module's performance gains globally in Phoenix?
If the answer is yes, it might make sense to rally the community around conditionally leveraging the json module in Jason if the former is available, as that would provide a sensible bridge to the desired future state.
Hi @michalmuskala, do you have plans to consume the new Erlang
json
module inJason
for future versions?https://www.erlang.org/blog/highlights-otp-27/#the-new-json-module
The
Jason
DSL with options, encoder protocol and the contract used by other libraries (Postgrex, Phoenix, Plug, etc) is handy.The
json
module is faster, but I don't see me using this Erlang module directly in my applications in place ofJason
.The text was updated successfully, but these errors were encountered: