Hi, author of this devlog here! Not to dismiss concerns about breaking language changes, but there seems to be a bit of a misconception here that this compiler change was highly breaking and will require significant effort from Zig users to update for. Perhaps I unintentionally gave that impression in the devlog or the PR writeup, apologies if so---but it's not the case! Although there were breaking changes in this patch, they were quite minor: most users are unlikely to hit them, and if they do then they're straightforward to deal with.
For a concrete example, while testing this branch, I tried building ZLS (https://github.com/zigtools/zls/). To do that, the only change I had to make was changing `.{}` to `.empty` in a couple of its dependencies (i.e. not even in ZLS itself!). This was needed because I removed some default values from `std.ArrayList` (so the change was in standard library code rather than the language). Those default values had actually already been deprecated (with intent to remove) for around a year, so this wasn't exactly a new change either.
As another example, Andrew has updated Awebo (https://codeberg.org/awebo-chat/awebo), a text and voice chat application, to the new version of Zig. Across Awebo's entire dependency tree (which includes various packages for graphics, audio, and probably some other stuff), the full set of necessary changes was:
* Same as above, change `.{}` to `.empty` in a few places, due to removal of deprecated defaults
* Add one extra `comptime` annotation to logic which was constructing an array at comptime
* Append `orelse @alignOf(T)` onto an expression to deal with a newly-possible `null` case
These are all trivial fixes which Zig developers would be able to do pretty much on autopilot upon seeing the compile errors.
So, while there were a handful of small breaking changes, they don't seem to me like a particularly big deal (for a language where some level of breakage is still allowed). The main thing this PR achieved was instead a combination of bugfixes, and enhancements to existing features (particularly incremental compilation).
I made one of the comments that seems to be perceived a critical of the changes (I made a statement about the seemingly brief paragraph on changing semantics). As I replied to Andrew, I will tell you: the PR had a large amount of planning and implementation that seems of great quality. I certainly did not intend to discredit you or the obviously large amount of work you have done previously or on the change. I guess that will teach me to post without even more caveats.
Oh, no problem at all & no shade of any kind intended! I just wanted to clarify this point since it seems like a good few people got that misconception. That doesn't mean you can't discuss breakage anyway, or ask questions of the development / language design process :)
I am going to ask a question that is is definitely not the place for, but I am not involved with Zig in any way and am curious, so I hope you'll indulge me.
I noticed the following comment was added to lib/std/multi_array_list.zig [0] with this change:
/// This pointer is always aligned to the boundary `sizes.big_align`; this is not specified
/// in the type to avoid `MultiArrayList(T)` depending on the alignment of `T` because this
/// can lead to dependency loops. See `allocatedBytes` which `@alignCast`s this pointer to
/// the correct type.
How could relying on `@alignOf(T)` in the definition of `MultiArrayList(T)` cause a loop? Even with `T` itself being a MultiArrayList, surely that is a fully distinct, monomorphized type? I expect I am missing something obvious.
I had to search for this, but managed to find the relevant mlugg@ comment[0] on the ZSF zulip:
> i had to change the bytes field from [*]align(@alignOf(T)) u8 to just [*]u8 (and cast the alignment back in the like one place that field is accessed). this wasn't necessary for MultiArrayList in and of itself, but it was necessary for embedding a MultiArrayList(T) inside of T without a dependency loop, like
const T = struct {
children: MultiArrayList(T),
};
// reproduced for completeness:
fn MultiArrayList(comptime T: type) type {
return struct {
bytes: [*]align(@alignOf(T)) u8,
// ...
};
}
Zig team member here: we've migrated to Forgejo Actions [0], which is a system built into Forgejo (the Git forge used by Codeberg) which is very similar to GitHub Actions. In fact, while 1-to-1 compatibility is a non-goal, it's almost compatible---many GHA workflows will run with minimal (or no!) changes, and most Actions written for GHA will work fine (e.g. my setup-zig Action [1] worked without changes). I don't necessarily love the design of GitHub Actions, and obviously that's all inherited in Forgejo Actions, but the issues I have with GitHub's implementation are pretty much all solved in Forgejo (plus they're receptive to PRs if you do need to improve something!). Codeberg offer a couple of free hosted runners (x86_64-linux), though they have quite aggressive usage limits (understandably, since Codeberg can't just throw money at free compute for everyone!) so self-hosting is probably kind of necessary for big-ish projects. That's pretty easy though: the runner [2] is trivial to build (including cross-compiling) and run, and is on the whole just a much more solid piece of software, so it's already been very painless compared to what it was like to self-host GitHub's runner. On the whole, Forgejo Actions has really just felt like a much more refined and cared-for version of GitHub Actions; I'm quite happy with it so far.
GitHub's API has extremely aggressive rate limits which make migrating large numbers of existing issues and PRs off of the platform borderline impossible. AIUI, this is why Gitea's main repo is on GitHub: they couldn't figure out a way to cleanly migrate! The tinfoil hat in me absolutely sees this as an attempt at vendor lock-in on GitHub's end.
Forgejo Actions is what Zig has migrated to. It's very similar to GitHub Actions; the downside of that is that you inherit questionable design choices, but the big upside is that migration is super easy. While they don't target 1:1 compatibility, things are similar enough that you basically only need to tweak workflow files very slightly. Our experience so far is that it fixes most of our serious problems with GitHub Actions; in particular, their runner software is significantly easier to deploy and configure, has much better target support (GitHub's runner is essentially impossible to use outside of x86_64/aarch64 linux/windows/macos; we tried to patch it to support riscv64-linux and got stuck on some nonsensical problems on GitHub's side!), and actually accepts contributions & responds to issues. My issues with the GitHub Actions' backend & web interface (of which I have many) are pretty much all gone, too, with no new issues taking their place.
This is extremely misleading. "Membership" is about direct contribution to and influence over the non-profit; it'd be somewhat analagous to being a GitHub shareholder. The very first question on Codeberg's FAQ [0] makes this abundantly clear, as does the "Join" page [1]. I don't see any part of the website you could go to to get any other impression.
This was the very first thing I noticed when we (the Zig team) started seriously trialing Codeberg. Honestly, the transition was worth it just for the ability to navigate the website without a 3-5 second wait every time I click a link.
I think this thread caused a bit of a hug of death; I too was seeing pretty bad page loads earlier today, but that seems to have sorted itself out. Understandable imo, because Codeberg simply haven't had to deal with this level of traffic so far. I'm optimistic that they'll be able to scale as (thanks to projects like Zig making the switch) their needs grow.
> This has been pointed out to them many times, and it's seemingly not something they're willing to fix.
On the exact page you're on is a link to an issue [0] acknowledging that the CAPTCHA is inaccessible and expressing that they plan to drop it (albeit with no concrete time-frame). I don't at all understand your argument that Codeberg must be slow at replying to emails (the "manual fallback path") because Wikimedia are; these are two completely unrelated entities and I don't see why you would make inferences about one from the other.
PRs are not optional: there is no way to disable them on GitHub. I can't be sure that this is intentional, but it certainly works out well for them that this is one of many properties which make it quite difficult to migrate away from the platform.
Yeah, that's actually what we've done on the Zig GitHub repository. However, it doesn't stop pushes to existing PRs, which isn't ideal; and, yes, it's quite hard to escape the conclusion that there being no "until I turn it back on" option is intentional.
It's completely intentional, and goes back to when GitHub was founded. GitHub was intended as a collaborative software development platform, not "look but don't touch".
I suppose you can fork a repository if you want to collaborate with others though. Reviewing pull requests and engaging with a community is a lot of work and has possible legal ramifications; in many cases it’s faster to just do things yourself. Some teams/companies deliberately refuse outside contributions for this reason.
You can close them and limit discussion to contributors I guess? Not ideal but at least they wouldn’t appear in the pull requests tab.
Alternatively you can use a bot or a GitHub Action to automatically change the description and title of the pull request to something like “[PRs are not allowed and deleted automatically]”. But yeah not a perfect solution either…
* Global variables still exist and can be stored to / loaded from by any code
* Only convention stops a function from constructing its own `Io`
* Only convention stops a function from reaching directly into low-level primitives (e.g. syscalls or libc FFI)
However, in practice, we've found that such conventions tend to be fairly well-respected in most Zig code. I anticipate `Io` being no different. So, if you see a function which doesn't take `Io`, you can be pretty confident (particularly if it's in a somewhat reputable codebase!) that it's not interacting with the system (e.g. doing filesystem accesses, opening sockets, sleeping the thread).
reply