Can't speak to this as I don't RE for security purposes, but:

> no plugin support and rather limited IR.

this I'm profoundly confused by. BN has multiple IRs that are easily accessible both in the UI and to scripts. And it certainly has a plugin system too.

I've used IDA, Ghidra, and Binary Ninja a lot over the years. At this point I much prefer Binary Ninja for the task of building up an understanding of large binaries with many thousands of types and functions. It also doesn't hurt that its UI/UX feel like something out of this century, and it's very easy to automate using Python scripts.

> I thought it was stable enough initially but they completely broke fuzz testing feature and didn’t fix it.

From the 0.14.0 release notes:

> Zig 0.14.0 ships with an integrated fuzzer. It is alpha quality status, which means that using it requires participating in the development process.

How could we possibly have been more explicit?

Fuzzing will be a major component of Zig's testing strategy in the long term, but we clearly haven't had the time to get it into shape yet. But we also didn't claim to have done!

> Also some things like stack traces were broken in small ways in zig. It would report wrong lines in stack traces when compiling with optimizations. Also wasn’t able to cleanly collect stack traces into strings in production build.

I mean, to be fair, most compiled languages can't give you 100% accurate source-level stack traces in release builds. But that aside, we have actually invested quite a lot of effort into std.debug in the 0.16.0 release cycle, and you should now get significantly better and more reliable stack traces on all supported platforms. If you encounter a case where you don't, file a bug.

> And recently saw they even moved the time/Instant API to some other place too. This kind of thing is just super annoying with seemingly no benefit. Could have left the same API there and re-used it from somewhere else. But no, have to make it “perfect”

I acknowledge that API churn can be annoying, but it would be weird not to aim for perfection prior to 1.0.

> You mean like how Rust tried green threads pre-1.0? Rust gave up this one up because it made runtime too unwieldy for embedded devices.

The idea with making std.Io an interface is that we're not forcing you into using green threads - or OS threads for that matter. You can (and should) bring your own std.Io implementation for embedded targets if you need standard I/O.

Are you sure that's still the case? I just checked the Raspberry Pi Imager and I see several "stock" distro options that aren't Raspbian.

Regardless, I take your point that we're reliant on vendors actually doing the upstreaming work for device trees (and drivers). But so far the recognizable players in the RISC-V space do all(?) seem to be doing that, so for now I remain hopeful that we can avoid the Arm mess.

It is of course possible that Debian sticks with RV64GC for the long term, but I seriously doubt it. It's just too much performance to leave on the table for a relatively new port, especially when RVA23 will (very) soon be the expected baseline for general-purpose RISC-V systems.

It's honestly a bit hard to understand why they bothered with this one. No hate for the Milk-V folks; I have 4 Jupiters sitting next to me running in Zig's CI. But hopefully they'll have something RVA23-compliant out soon (SpacemiT K3?).

One of the nice things about switching to Forgejo Actions is that the runner is lightweight, fast, and reliable - none of which I can say for the GitHub Actions runner. But even then, it's still more bloated than we'd ideally like; we don't need all the complexity of the YAML workflow syntax and Node.js-based actions. It'd also be cool for the CI system to integrate with https://codeberg.org/mlugg/robust-jobserver which the Zig compiler and build system will soon start speaking.

So if anything, we're likely to just roll our own runner in the future and making it talk to the Forgejo Actions endpoints.

We had technical problems that GitHub had no interest in solving, and lots of small frustrations with the platform built up over years.

Jumping from one enshittified profit-driven platform to another profit-driven platform would just mean we'd set ourselves up for another enshittification -> migration cycle later down the line.

No stunt here.

In fact, we do already have cross-compilation support for NetBSD (and FreeBSD). But we currently only "test" NetBSD by building the language behavior tests and standard library tests for it on Linux, i.e. we don't actually run them, nor do we build the compiler itself for NetBSD. Native CI machines will allow us to fill that gap.

As it happens, Go's cross-compilation support does indeed make our lives easier for provisioning CI machines since we can build the Forgejo Runner for all of them from one machine: https://codeberg.org/ziglang/runner/releases/tag/v12.0.0

If IBM cannot get Microsoft to work with them on something so small but impactful, there's no chance we can.

> Personally - I think GitHub is a cultural artifact now. Of the entire planet. Hackers and curious minds from Japan to Alaska and everything in-between flock to GitHub.

And it's in the hands of a for-profit company pushing LLM nonsense. That should be alarming! Let's instead encourage people to use platforms managed by non-profits.

Believe it or not, there are platforms outside of the big 3.

The GitHub Actions runner does not work on FreeBSD, NetBSD, OpenBSD, and illumos, all of which are operating systems we either have existing support for, or intend to start supporting properly soon. (We already have FreeBSD CI; machines for the other 3 are arriving at my place tomorrow as it happens.)

And that's ignoring CPU architectures; the upstream GitHub Actions runner only supports x86 and aarch64. We had to maintain a fork that adds support for all the other architectures we care about such as riscv, loongarch, s390x, etc. We will also likely be adding mips64 and powerpc64 to the mix in the future.

Even IBM have to maintain an s390x fork because Microsoft can't even be bothered to accept PRs that add more platforms: https://github.com/uweigand/runner

So you just chose to ignore the technical problems we have with GitHub Actions and then say there are no problems. That's certainly a take.

> That CI system created by so called monkeys is the one of the best free CI service in the world.

We self-host all our CI machines so the "free" hosted runners have no relevance here.

> Not everyone has the millions of dollars like Zig Foundation to create their own CI servers.

We don't have "millions of dollars". If only!

I'd also note that we spend our money very efficiently; most of our CI machines are consumer-grade hardware hosted in team member's homes. We don't just throw endless amounts of money at cloud providers.

> After that they appreciate GitHub Sponsors, but say it is now a complete liability just because a project leader left. What are the actual changes? Any new rule? But no, it is now a "liability" and we should accept it.

GitHub Sponsors is a liability because Microsoft can increase their cut at any time, or even axe it outright if they don't think it's profitable for them anymore. This risk is very real considering that, as Andrew pointed out, the feature has been neglected for years. It is objectively less risky for us to have donors use a platform like Every.org.

We do self-host all our CI machines.

Can't say I agree with this point. Zig has been trying out Forgejo/Codeberg as an alternative to GitHub, and about two months into the experiment, almost all of our technical concerns with Forgejo (and Forgejo Actions) have been addressed, with the only straggler being a UI bug related to the Cancel button in the Actions infrastructure (which has a WIP PR open, and which also has a straightforward workaround).

I can't speak to the platforms themselves, but in regards to their CI systems, it looks to me like the Forgejo Actions runner sees more development than the Gitea act_runner. For example, Forgejo gained support for concurrency groups recently, which to my knowledge are still not supported in Gitea.