[grayhatter]

IMO, it's very wrong. Zig's language is not drastically changing, it's adding a new, *very* powerful API, which similar to how most everything in zig passes an allocator as a function param, soon functions that want to do IO, will accept an object that will provide the desired abstraction, so that callers can define the ideal implementation.

In other words, the only reason to not use zig if you detest upgrading or improving your code. Code you write today will still work tomorrow. Code you write tomorrow, will likely have a new Io interface, because you want to use that standard abstraction. But, if you don't want to use it, all your existing code will still work.

Just like today, if you want to alloc, but don't want to pass an `Allocator` you can call std.heap.page_allocator.alloc from anywhere. But because that abstraction is so useful, and zig supports it so ergonomically, everyone writes code that provides that improved API

side note; I was worried about upgrading all my code to interface with the new Reader/Writer API that's already mostly stable in 0.15.2, but even though I had to add a few lines in many existing projects to upgrade. I find myself optionally choosing to refactor a lot of functions because the new API results is code that is SO much better. Both in readability, but also performance. Do I have to refactor? No, the old API works flawlessly, but the new API is simply more ergonomic, more performant and easier to read and reason about. I'm doing it because I want to, not because I have to.

Everyone knows' a red diff is the best diff, and the new std.Io API exposes an easier way to do things. Still, like everything in zig, it allows you to write the code that you want to write. But if you want to do it yourself, that's fully supported too!

[do_not_redeem]

This isn't quite accurate. If you look at the new IO branch[1] you'll see (for example) most of the std.fs functions are gone, and most of what's left is deprecated. The plan is for all file/network access, mutexes, etc to be accessible only through the Io interface. It'll be a big migration once 0.16 drops.

[1]: https://github.com/ziglang/zig/blob/init-std.Io/lib/std/fs.z...

> Do I have to refactor? No, the old API works flawlessly

The old API was deleted though? If you're saying it's possible to copy/paste the old stdlib into your project and maintain the old abstractions forward through the ongoing language changes, sure that's possible, but I don't think many people will want to fork std. I copy/pasted some stuff temporarily to make the 0.15 migration easier, but maintaining it forever would be swimming upstream for no reason.

[grayhatter]

> most of the std.fs functions are gone, and most of what's left is deprecated.

uhhh.... huh? you and I must be using very different definitions for the word most.

> The old API was deleted though?

To be completely fair, you're correct, the old deprecated writer that was available in 0.15 has been removed https://ziglang.org/documentation/0.15.2/std/#std.Io.Depreca... contrasted with the master branch which doesn't provide this anymore.

edit: lmao, your profile about text is hilarious, I appreciate the laugh!

[do_not_redeem]

Even the basic stuff like `openFile` is deprecated. I don't know what else to tell you. Zig won't maintain two slightly different versions of the fs functions in parallel. Once something is deprecated, that means it's going away. https://github.com/ziglang/zig/blob/init-std.Io/lib/std/fs/D...

[grayhatter]

Oh, I guess that's a fair point. I didn't consider the change from `std.fs.openFile` to `std.Io.Dir.openFile` to be meaningful, but I guess that is problematic for some reason?

You're of course correct here; but I thought it was reasonable to omit changes that I would describe as namespace changes. Now considering the audience I regret doing so. (it now does require nhe Io object as well, so namespace is inarticulate here)

[Ar-Curunir]

That is literally a breaking change, so your old code will by definition not work flawlessly. Maybe the migration overhead is low, but it’s not zero like your comment implies

[bccdee]

> I didn't consider the change from `std.fs.openFile` to `std.Io.Dir.openFile` to be meaningful, but I guess that is problematic for some reason?

Because you explicitly said that existing code would continue to work without `std.Io`.

> Code you write tomorrow, will likely have a new Io interface, because you want to use that standard abstraction. But, if you don't want to use it, all your existing code will still work.

I like Zig, but it does not have a stable API. That's just how it is.

[grayhatter]

> Because you explicitly said that existing code would continue to work without `std.Io`.

Because I'm not conflating passing an Io object, (what everyone expects to be mandatory) and existing APIs moving into the Io namespace (an API change that can only be considered significant if you're trying to win an argument on reddit).

These are drastically different changes, and only one can be considered a meaningful change.

> I like Zig, but it does not have a stable API. That's just how it is.

The last 3 minor version upgrades, required a diff in all of my projects. All of them could have been fixed with exclusively sed -i to update namespaces. None of them required real attention, or logic changes.

In one repo I made the namespace changes in isolation. After some time I then went back and rewrote a few blocks to take advantage of the features, runtime speed improvements, and generally improved code quality granted from the new API.

I don't expect zig's API to be stable, and I regret it if my comment gave you a different impression. But I stand by my comments because I respectfully refuse to ignore the pragmatics of using zig. Calling moving a function between namespaces breaking API change can be argued as technically correct, but bordering on being intentionally misleading.

[brabel]

> Code you write today will still work tomorrow.

Haha no! Zig makes breaking changes in the stdlib in every release. I can guarantee you won’t be able to update a non trivial project between any of the latest 10 versions and beyond without changing your code , often substantially, and the next release is changing pretty much all code doing any kind of IO. I know because I keep track of that in a project and can see diffs between each of the latest versions. This allows me to modify other code much more easily.

But TBH, in 0.15 only zig build broke IIRC. However, I just didn’t happen to use some of the things that changed, I believe.

[grayhatter]

> But TBH, in 0.15 only zig build broke IIRC. However, I just didn’t happen to use some of the things that changed, I believe.

I idle on IRC a lot, and try to help out with questions. From that view, this is the experience of over 90% of users. Minor namespace changes, or calling a function with a different named option. . root_source_file became . root_source_module (and required an additional function call)

Complex changes are almost never required, and IMO shouldn't be expected by most people using zig. Those who might need to make them, already know they're coming because they're already paying attention to the language as a prerequisite for writing such complex code. (Complex here meaning depending on the more esoteric zig stdlib internals)

[kunley]

Zealotry in almost every paragraph.

[grayhatter]

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.

[kunley]

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?

[grayhatter]

> 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?

[kunley]

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).