Zig team member here---obviously I can't say for sure yet, but I'm pretty confident the number will be basically identical. In the Zig compiler, incremental updates (rebuilds) have a small amount of overhead which is roughly proportional to the total size of the codebase (rather than just the amount of code which was changed). This comes from a) detecting which source files changed, and b) traversing a graph to figure out which declarations are referenced (necessary due to Zig's "lazy analysis" feature). But performance analysis reveals that for small updates, this overhead actually dominates the update time, by a lot. Of the 35ms, I would guess that under 5ms are actually spent rebuilding the function(s) that changed. Of that 5ms, code generation---the only thing which would really be different on AArch64---is an even smaller slice of the pie (it often doesn't even impact the overall time, since it runs in parallel with other parts of the pipeline, and those other parts are usually the bottleneck there). So even if the AArch64 backend was significantly slower (which, right now, is the opposite of what we expect---instruction selection and encoding for x86_64 is unusually complicated!), I wouldn't expect the number to change from 35ms.
Worth noting that while it's absolutely unfortunate that we're hitting this Forgejo design flaw, AGit honestly is just a better workflow, and I (Zig core team member here, full push access to the upstream repo) have started using it for pretty much all of my PRs. There are a couple of small things I'd like to see improved about Forgejo's implementation of AGit, but IMO it fundamentally makes so much more sense than the two-step push-then-PR workflow (especially if you're an external contributor who would also need a first step of "fork the repo").
`u3` would be base 8, i.e. octal---I think you meant to use `[400]u6`?
Aside from that: I'm not familiar with how standard base64 deals with endianness, so I'm not sure if it would match that, but this `@bitCast` would certainly give you a base64 encoding. But it would probably emit pretty terrible code to do that---our lowering of `@bitCast` isn't really optimized for moving around huge amounts of data in one operation! (But maybe LLVM would surprise me.)
Uh, no? My writing style just happens to include a lot of em-dashes, as is very common. And it's not like I'm pasting a weird Unicode codepoint all over the place, that's just (rightly) how my Markdown gets rendered...
What do you mean by "interim"? As I explicitly stated in the comment you quoted, it has never, and likely will never, been planned for the Zig compiler to become incapable of using LLVM. The LLVM backend still sees plenty of active development by the core team [0]---that's perfectly compatible with improving the experience of users (including ourselves) by avoiding unnecessary uses of LLVM [1].
> ...is for Zig to generate LLVM binary files that can be passed to a separate LLVM instance as part of the build process. Is that "a first-class supported backend target for compilation"? I suppose it's a matter of semantics, but that certainly won't be the current LLVM backend that does LLVM API calls.
I think you are incorrectly assuming that we currently make heavy use of the LLVM API. As indicated by #13265 being closed, that is not true. The Zig compiler already generates bitcode by itself, without touching the LLVM API. The only thing we actually use the LLVM API for is feeding that bitcode to LLVM, which can easily be done by invoking a CLI instead. Users quite literally would not be able to tell if, for instance, we changed the compiler to pass the bitcode to Zig's embedded build of Clang over CLI.
Hm, are you referring to the CI failure on the x86_64-linux-release CI job on the current tip of master on the main Zig repository? That one's a flaky test, not indicative of a serious problem. (We usually just disable flaky tests, but this particular one I'm leaving on for the moment to try and gather a little more information about it.)
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 :)
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).
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.
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.
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.
> 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.
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.
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.
If `foo` needs to do IO, sure. Or, more typically (as I mentioned in a different comment), it's something like `const x = something.foo()`, and `foo` can get its `Io` instance from `something` (in the Zig compiler this would be a `Compilation` or a `Zcu` or a `Sema` or something like that).
> Using stackless coroutines and green threads results in a completely different codegen.
Sure, but that's abstracted away from you. To be clear, stackless coroutines are the only case where the codegen of callers is affected, which is why they require a language feature. Even if your application uses two `Io` implementations for some reason, one of which is based on stackless coroutines, functions using the API are not duplicated.
> I wonder what will happen if you try to await a future created with a green thread IO using a stackless coroutine IO.
Mixing futures from any two different `Io` implementations will typically result in Illegal Behavior -- just like passing a pointer allocated with one `Allocator` into the `free` of a different `Allocator` does. This really isn't a problem. Even with allocators, it's pretty rare for people to mess this up, and with allocators you often do have multiple of them available in one place (e.g. a gpa and an arena). In contrast, it will be extraordinarily rare to have more than one `Io` lying around. Even if you do mess it up, the IB will probably just trip a safety check, so it shouldn't take you too long to realise what you've done.