GitHub Actions are seriously broken and that alone is a technically sound enough reason to move: the sleep.sh bullshit has degraded the performance of our CI for a long time, as it regularly livelocks in an endless while(true) spin runner agents, who stop processing new jobs. The agent itself has poor platform support also because it has a runtime dependency on .NET, and lately GH Actions started running jobs out of order with the result that old jobs would starve and time out, causing PRs to turn up red for no real reason.
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".
As a side note, people said that not posting anymore on Twitter and leaving Reddit was also a death sentence for Zig. Time has passed and we're still alive so far, while in the meantime both platforms have started their final journey towards the promised lands of the elves.
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.
I hope the best for Zig, Loris. But even if Zig will survive and prosper (I hope for both), still I believe this is not a sounding decision and not the right attitude. I hope I'm wrong, but I wanted to share with you my reasoning. Here you are moving away from the open source marketplace AND from your main revenue stream. It's not similar to not posting anymore to Twitter. A better parallel would be not posting anymore on Hacker News anything Zig related, in terms of potential outcome.
We've been directing people to use other means to donate for a few years now, so GH Sponsors is not our main source of income anymore (and hasn't been for a while). It's still a significant chunk, but it's also not going to go away overnight.
> 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 :^)
> It's still a significant chunk, but it's also not going to go away overnight.
You despise and are leaving GitHub, but intend to keep collecting money from their sponsorship feature/program? Sounds like they are doing something right then…
I had to scroll too far for someone to mention third-party CI. GitHub Actions free runners have always sucked, but the third-party runner ecosystem is really strong for those who can afford it. imo the APIs are far better than the rest of the product - I suspect enterprise customers are strong-arming GitHub to keep them reliable. and there's always third-party CI like tekton if Actions' yaml is too annoying
Namespace fixed all of the issues I had with GitHub Actions. Ghostty uses them to build their project: https://namespace.so
Using Namespace made it clear how much cruft GitHub Actions has accumulated and how much performance they leave on the table. I regard GitHub Actions like Nix: weird configuration, largely shell-based, and the value you get out is commensurate with the investment you put in. But it works well enough.
But at the end of the day, GitHub Actions, like Nix, is just shell scripts. They're fairly portable. I like Namespace because they fixed the parts of CI that matter, like fast local caching versus GitHub's HTTP-based cache.
But I also don't hate this: I use GitHub for the pretty website and global search. Someone will mirror Zig for the search, and my terminal does not care where I clone the repository from. I think this is the new world we live in.
Someone will have to build the aggregator that indexes all repositories and makes them searchable, but that can ultimately be separate from hosting.
Some people like Zig because it makes it easier to learn how to program the machine sitting in front of them.
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.
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.
> As a small example wrt Rust: resetting an arraylist/vector while reusing its memory is a weirdly complicated trick
A bit of a nitpick here: the trick is for creating a new vector of a different type, that reuses the allocation of an existing vector, using only safe code. "Resetting an arraylist/vector while reusing its memory" is just vec.clear() if you're not changing the type. And it's trivial to change the type of a vector with unsafe (the docs even have examples of this); the only advantage of the "trick" is to ensure you'll get a panic if you screw up the alignment of the types.
And after that blog post, the Rust team accepted a proposal to introduce a vec.recycle() function to change the type of a vector without needing that trick (and with compile-time checks for alignment compatibility): https://github.com/rust-lang/rust/pull/148416
But that example aside, I agree with your overall premise -- Zig and Rust share different design goals here, and Zig's lower level of abstraction makes it more approachable to learn than a language like Rust.
This writing is absolutely too vapid (even as far as AI slop goes), especially for the kind of jabs it makes at Rust.
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.
What would be the level of Zig knowledge needed to do this exercise?
Or, asked differently, with no knowledge of Zig, what would be a realistic approach to trying this out? (Assuming an interest in learning Zig, with a background in C++)
It's definitely possible to hit the ground running you have some knowledge of systems programming. I would say that the Zig version is much easier to understand than the C version provided by the book because the Zig one uses `packed structs` instead of bit operations in some places, everything else is roughly the same.
The longevity of donation platforms is a major concern for us and GitHub has not been good in that sense.
GitHub Sponsors has not seen a single improvement in the years after its launch (despite us and other organizations chatting with GitHub employees about critical missing features), and GitHub Actions has been tragicomically buggy, clearly showing that software engineering infrastructure is not GitHub's core focus anymore (on top of, you know, the CEO explicitly saying that GitHub is an AI company now).
Since we do see ourselves eventually migrating away from GitHub (at least in some form), we would like to steer donations towards a service that we have higher confidence in.
So in practice money is effectively being donated (donating hw is not free) to be spent on CI, not very differently than in our case, but you're delighted to not know the numbers and like to imagine it's $0. Ok :^)
Thank you! I've learned how to use it well enough for own my needs by now but I think it would be really helpful to beginners if links to this video and any other useful resources you know about were added to the "Zig Build System" page on your website.
Zig is not really a handmade project, case in point both Andrew and I are blocked on social media by the two gods of the handmade movement (casey and john) and, according to their die hard fans, Andrew gave a talk at the last handmade conference that caused the community to split apart (the reality is a bit more complex than this, but Andrew's talk is certainly one that you wouldn't see at their new "better software" conference).
Depends on the attitude, not using an engine, because one wants to learn the whole stack, makes all sense, after all people need to learn how to make game engines, if nothing else for the next generation.
Not using one out of spite, because we do everything handmade over here attitude, is a completely different matter.
Unfortunately for everyone, people like you tie their entire identity and income to specific technologies, movements, or communities—becoming deeply tribal in the process. When something or someone undermines their sense of security—even with constructive criticism—they react defensively, often to the point of ignorance.
All this, combined with the fact that Zig, at best is still in beta quality and at worst amounts to a massive waste of everyone’s time, makes it unsurprising that people block you and simply refuse to engage with your loud community efforts, endless churn and crust tied to beta quality compiler.
> Zig is not really a handmade project, case in point both Andrew and I are blocked on social media by the two gods of the handmade movement (casey and john) and, according to their die hard fans, Andrew gave a talk at the last handmade conference that caused the community to split apart (the reality is a bit more complex than this, but Andrew's talk is certainly one that you wouldn't see at their new "better software" conference).
In the first, at 2:30:40, Andrew Kelly publicly calls out a specific author of a competing technology in exaggerated, caricatured, and fabricated context.
In the second video, yet another author of a yet another competing technology directly points out this unapologetic and concerning behavior on Andrew Kelly’s part.
And now you—“VP of Community @ Zig Software Foundation”—assert your “righteous” stance by sharing these videos, while ironically pointing out that some of those same individuals (of competing technologies fame) block you on social media.
Too bad that doing your job probably means being as loud and visible online as possible to spread the molecules of Zig no matter what.
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".