I mean, zig has made writing code something I enjoy again, instead of being something I hate. So I don't mind the title of zealot, I'm sure you meant it as an insult, but I have no intention to apologize for finding some lost joy, and being excited about it.
Well I called it a zealotry not as an insult but to redirect your attention to how this style of expression is seen by others. For instance:
> In other words, the only reason to not use zig if you detest upgrading or improving your code
So you were saying that my own ways of upgrading or improving my code are ruled out, because the only way is via rewriting it for every new language release, right? That's the kind if religious statement I am against.
> Code you write today will still work tomorrow
No it will not and wasn't so far.
Where is the room for exchanging the views and experiences if statements are contradicting the facts?
> So you were saying that my own ways of upgrading or improving my code are ruled out, because the only way is via rewriting it for every new language release, right? That's the kind if religious statement I am against.
No, you misunderstood the idea I was trying to explain. Skill issue, almost certainly more mine than anybody else, but I try very hard to ask more questions than throw around judgements.
In the context of the question "Am I wrong that because things will change soon, today is a bad day to learn zig" The answer is no, because all the code you wrote, and all the stuff you learned about zig, will still apply when 0.16 is released. There will be no meaningful changes in 0.16 that invalidate everything from 0.15.
do note; I'm omitting details like needing to rename ArrayList to ArrayListManaged (an example change from the previous release) Because I'm trying to practice giving more attention to the pragmatics, over the semantics, because there's more opportunity for growth there contrasted with online pedantry.
So given the most significant change between 0.15.2 and 0.16.0 Will be a new, better API, that I believe from experience (e.g. the previous Readed/Writer change that I originally was skeptical about) will result in my code becoming better.
Thus, the idea is: If you don't enjoy constantly improving code, you won't enjoy Zig throughout it's 0.x cycle. The rate of improvement is very rapid. But as someone who enjoys the pride from committing a change where I see the new code as objectively better. I enjoy improving my code, so this isn't a reason not to, please note, I made my original comment with "In My Opinion". I could probably invent other arguments I could coerce into this context, but that feels disingenuous.
Thus I stand behind my assertion, given the changes you'll likely see, you don't have to upgrade your code, the raw API will still exist, but why wouldn't you? (please keep in mind the pedantry I'm intentionally ignoring as not interesting, I'm not afraid of using sed -i, or editor macros)
> Where is the room for exchanging the views and experiences if statements are contradicting the facts?
how about: This grayhatter fellow seems to be lacking the perspective of reality that I feel is obvious, I should ask why he's ignoring it, omitting it, or ignorant to it. Perhaps he knows something I don't and is bad at explaining it.
vs
I disagree, so I'll instead make a driveby judgement and call him a zealot, instead of being curious.
> Well I called it a zealotry not as an insult but to redirect your attention to how this style of expression is seen by others.
How'd that work? Because I thought you were just trying to be an asshole. For the record, I still don't believe this, it feels much more likely to me this is you trying to retcon an unkind comment you made casually without much thought, rather than taking ownership of the regret over poor communication. Roles reversed, would you believe I meant to encourage exchanging views had I called you a zealot?
You don't have any reasons to call me a zealot.. yet. Symmetrism doesn't work.
You wrote so many paragraphs but at the end it's clear for me that you're talking about improving the code for the sake of improving the code - and not where you decide but where language authors decided (because they have changed something).