Two weeks after the previous meetup, it is time for another one!
The meetup will take place this Friday (April 23rd) at 3pm UTC. That is 5pm in central Europe, and to get the correct time in your timezone, please use https://time.is or some similar service.
This time Araq plans to talk less and listen more :) Prepare your questions and/or share your experiences, pain points, success stories, etc.
Join us at: https://meet.jit.si/NimDevMeet (no registration needed)
please use https://time.is or some similar service.
Here is a link that will work for everyone, no matter their timezone: https://time.is/compare/1700_23_Apr_2021_in_Germany
I joined the meeting late but there was on interesting conversation on how to evolve stdlib (starting from the example: there is a faster json than the one in stdlib, but with a different api, how can we make it available in stdlib?). Is there a place where this discussion is ongoing? (someone mentioned a RFC but I cannot seem to find one).
Also would be curious to know the subjects of the first part of the call (did you talk about the next nimconf? saw some mentions of it in the chat).
I find that this format of online meetup is anyway very interesting, thanks for organizing it, and thanks to those who participated and discussed!
someone mentioned a RFC but I cannot seem to find one
There was a rejected RFC from me, but I meant to encourage participants to write a new one. Sorry for the confusion.
@Araq Thoughts?
Ok I see the rejected RFC: https://github.com/nim-lang/RFCs/issues/310
And also a new one by Pmunch: https://github.com/nim-lang/RFCs/issues/371
I agree more or less with the picture sketched by @kaushalmodi:
Btw this also applies to current stdlib situation for regex (nre vs re) where possibly one of the two should be a nimble package and the other remain in stdlib.
we break code for the people who import json2 from Nimble once it moved into the standard library (because the Nimble package then becomes outdated)
well the code does not break, it just does not receive updates.
then we break the code for the people who import json because eventually it changed its meaning
yes, we break code when changing the major version from 1.x to 2.x which is to be expected.
Another variation of this that stays inside of nim repo (instead of relying on nimble), does not use a json2 and allows to keep updating:
in this case for any major version n.x there exist up to 3 different json:
where do stuff break?
yes, we break code when changing the major version from 1.x to 2.x which is to be expected.
Does it mean that all nimble modules that currently importing json will not be compiled in Nim2? This sounds really terrible...
IMO, stdlib should employ stability index like this <https://nodejs.org/docs/latest/api/documentation.html#documentation_stability_index>. I saw some stdlib have already mentioning experimental API in text, but currently this is not very systematic or very clear to users.
json should be considered as stable api and should not be broken. json maybe marked as legacy and show a HORRIBLE warning during compilation. My gut feeling is that this is already enough to motivate >50% people to move away from json or module that touch json.
Personally, I value stability much much more than naming. And I don't really think that the name`json2` is bad. If you do think that json2 is ugly, then just name it another name e.g.`fastjson` or whatever. It is similar to all other nimble packages: If your desired name is already used, then pick another one.