As an example: https://github.com/kristoff-it/ziggy/blob/852053b09a5f8f5b79...

The part about mapping every error kind to different error code in Zig is debatable. It might be useful in some cases maybe (I don't have the confidence to fully exclude it), but at the very least in my experience I never ever needed that.

1. if you're a casual user (ie you don't follow the development) don't try incomplete APIs that not even the creators of fully know how they are supposed to work (because they're still tinkering with them) also you can't expect docs until the design is somewhat finalized (which is not yet, fyi)

2. llms don't help when trying to make sense of the above (a feature that is not complete, that has no docs other than some hints in commit messages, that changes every other commit), reserve llms for when things are stable and well documented, otherwise they will just confuse you further.

If you want to try new features before they land in a tagged release, you must engage with the development process at the very least.

it's full of wrong assertions about zig

That being said, I am guilty of helping building Zig communities on Discord, but in my defense none (literally none) of the FOSS alternatives was good enough at the time. And I'm also not really happy with plenty of the newer ones.

I'm now working on my own take of what an open source Discord alternative should look like and I plan to move away from Discord by the end of the year. You can find it on codeberg, it's called awebo, I'm intentionally not posting a link since these are super early days.

I made the mistake of leaving this unsaid, but 501c3 in the US also means that the company is tax exempt, which is the actual concrete thing I was implicitly asking about.

I haven't looked too deeply into it, but my understanding is that it's not possible to create an equivalent corporation in Italy (where I reside) nor the rest of Europe.

I would love to be proven wrong though.

You won't find easily Zig programmers that want you to use Zig at all costs, or that believe it's a moral imperative that you do. It's just antithetical to the whole concept of Zig.

The worst that can happen is that Zig programmers want C projects to have a build.zig so they can cross-compile the project trivially, since that's usually not a thing C/C++ build scripts tend to offer. And even then, we have https://github.com/allyourcodebase/ so that Zig users can get their build.zig scripts without annoying project maintainers.

https://github.com/kristoff-it/zig-okredis

> A better parallel would be not posting anymore on Hacker News anything Zig related, in terms of potential outcome.

I've been thinking about this lately and in my experience (having seen the effect of HN posts in the past when Zig was smaller vs now) the community is already big and vibrant enough that an HN post alone doesn't do too much of a difference. To be clear, I don't think that HN is losing relevance (unlike all the other big platforms mentioned earlier in this conversation), but our situation has changed.

People now are more and more learning about Zig though cool Zig projects, not by looking at yet another superficial language comparison blog post, which is the kind of content that tends to get to the top of HN more often than not.

More in general I think that your point about not pulling away from all the markeplaces of ideas is valid, but most of those marketplaces are not as good as they claim to be and we have the luxury to run a project that has a strong community connected to it, meaning that we won't be starved of attention or contributors by moving away from GitHub.

This whole situation has an interesting parallel with what's happening in our community wrt chat platforms, if we happen to be at the same tech event in person I'll be happy to share with you all the details :^)

They won't get there tomorrow or the next month, but I'm sure there has been a time where people started moving from Sourceforge to GitHub and somebody else remarked that they were doing something needlessly risky.

As far as we can tell Codeberg is a serious attempt at a non-profit code sharing platform and we feel optimistic enough about its future that we're willing to bet on it.

It's a real problem to run a project like Zig if your CI doesn't work. I guess we could have paid for an external CI service, but that as well would depend on GitHub APIs, so we would have gained what, a couple years? Given the current trajectory of GitHub I wouldn't trust them to maintain those APIs correctly for any longer than that (and as far as I know the current vibe-scheduling issues might already be reflected in the APIs that third party CI providers would use).

Let's not forget that "GitHub is an AI company now".

It's better at that than Rust because it's less abstracted, and it's better at that than C because you don't have to worry all the toolchain nonsense / weird conventions / weak type system of the C ecosystem.

As a small example wrt Rust: resetting an arraylist/vector while reusing its memory is a weirdly complicated trick https://lobste.rs/s/emvkea/why_we_didn_t_rewrite_our_feed_ha...

I think I don't need to provide references for C.

It's a new pathway to mastery that really works well for some people. That in itself is much more valuable than any new specific feature the language has to offer, although the ability of the toolchain to cross-compile reliably not only Zig but also C and C++ code does play into that.

And, while not yet 100% there, instant incremental rebuilds also help to achieve faster feedback loops.

People like Zig because it's a tool that helps them become better programmers, faster.

Zig is not the end solution to all problems, just like neither Rust is. Each is a sweetspot on the spectrum of possible solutions, each with it's own sets of pros and cons that appeal differently to different people.

It used to be that some Rustaceans would be aggressive against Zig and that has thankfully died down. We do not need to repeat the same the other way around, so please don't get baited by AI slop.

Also, you don't `catch unreachable` errors when printing to stdout.