alexrp

But you cannot state that people are "welcome to engage and debate the idea on its merits" when that clearly isn't the case.

I really didn't think that part had to be stated explicitly; I genuinely don't know why someone not invested in Zig would even feel the need to go debate on the Zig issue tracker. But even setting that aside, this is far from the first time that the core team has made it clear that we don't want the internet peanut gallery to brigade the issue tracker.

as evidenced by real comments being deleted from that issue.

Which real comments were deleted?

You don't need to be a Zig expert, but you do need to at least be invested in the Zig ecosystem in some way.

I think it's reasonable for any open source project to only be interested in the opinions of its actual users, especially when obvious social media brigading is taking place.

If I -- having written precisely 5 lines of Rust in my life -- showed up on the Rust issue tracker and started expressing my opinions on the future direction of the project and debating a proposed feature, I would absolutely expect people to be annoyed about the noise I'm generating.

The Zig issue tracker is for technical discussion; you are more than welcome to engage and debate the idea on its merits. But we do indeed delete meta-commentary, wild speculation, and outright hostility.

This is about a strictly-enforced form of run-time memory safety where there's no `unsafe` escape hatch that a careless programmer can misuse to undermine the memory safety mechanism. Contrasting with Rust is helpful to get that point across - which the body text of the issue does.

I can't speak for Andrew, but I didn't read this as a "diss" at all.

I think the Zig people are really just concerned that maybe Zig itself is a DOA language because it doesn't offer enough over C for any serious use

I promise you, hand on heart, that literally no one on the Zig core team is wasting their time on thoughts like this.

and their flagship project has now abandoned it.

Quoting Andrew:

So, when the Anthropic aquisition finally happened, we at ZSF breathed a sigh of relief. When the donation silently stopped, our bank account was ready for it. When they neither canceled their monthly meeting with us, nor showed up, we were not surprised. The relationship was over.

I advise you to take this paragraph at face value. Again, I promise you that it is the truth.

NT is optimized, since day one, to swap.

I'm not sure what point you're making here. Did you assume we had the page file disabled or something?

This is a feature, not a bug.

OOMing when there's tens of gigabytes of unused memory is a feature...?

Both Windows and macOS do so much better out of the box for essentially any workload.

We test FreeBSD, Linux, macOS, NetBSD, OpenBSD, and Windows in Zig's CI fleet. Of these, Windows is the only OS that we've had to configure with swap double the size of physical RAM to not hit completely unjustifiable OOMs.

By "unjustifiable", I mean that we're not even close to actually running out of physical memory (let alone swap), but the MM seems to be doing a horrible job of making unused memory actually available to processes.

It's possible there's a relevant configuration knob here that we're just not aware of... but the point is, the default behavior does in fact suck.

Their CI instances are over provisioned and time-out

I can't speak to their managed Jenkins offering, but FWIW, we've had no major trouble running Zig's CI on 3 s390x-linux VMs, each with 8x z15 vCPUs and 32 GB of RAM.

They are definitely over-provisioned, though, so we have the job timeouts set ~3 hours higher than they ideally should be to deal with load spikes. But after we dialed those timeout values in, it's been smooth sailing from there. I'd even say it's one of our most stable CI platforms now.

I did reach out to Bruce Gilkes about the over-provisioning and he informed me that they are planning an upgrade to z17 later this year, so hopefully that'll improve the situation.

What does an open source project get from this? ... So besides the bragging rights (I guess?) and discovering latent bugs exposed by the exotic architecture, what's in it for a project to deal with this extra architecture

The way I look at it, if Zig is going to be a serious C competitor, it must run in all the places that people run C in. Plus I just find it fun to do porting work since it involves a whole bunch of learning.

I only started using GPD products with the Pocket 4, so unfortunately I can't speak to your experience with the Pocket 2. I certainly hope the battery doesn't degrade that fast on their newer models...

The only thing I can say is that they seem to have significantly improved the thermals; IME, the Pocket 4 only gets moderately warm to the touch during full CPU load, and that's even with the quiet fan mode.

That's fair; the keyboard layouts are definitely an acquired taste. Not that I've quite acquired said taste myself... but for devices that I mainly use when traveling, I just don't particularly care that much. It'd probably be more of an issue if I was using one of them as my daily driver - but I still very much prefer my workstation at home for that.

Depends on what you're doing I suppose? I'm able to work on Zig with both of the devices I mentioned. Of course I'm limiting the test cases to the subset that's actually relevant to the area or target I'm working on. But that would be the case on a beefy full-size laptop too; even there, the full Zig test suite would take many hours and murder the battery in the process.

The CPU is just too underpowered; I'm sure it's fine for basic computery stuff, but building software and running medium/large test suites on it would be far too slow. Also not enough USB ports; I don't want to carry a USB hub with it.

Battery life on it is comparable to the MicroPC 2, but for the netbook form factor, it should really be compared to the Pocket 4. Similar story for the RAM, as well as the odd screen refresh rate.

Minor points: I do also appreciate the Ethernet ports on the GPD devices, and their approach to touchpads (buttons and placement in particular).

I guess my issues basically all boil down to the Minibook X not having enough functionality for the form factor when compared to GPD. That's mostly understandable for the price, but my point is just that if you're willing to fork over some more cash, you can get a whole lot more laptop in the same form factor (Pocket 4) or slightly better specs in a smaller form factor (MicroPC 2), and at least for me, that's the only way I could even have seriously considered these form factors for my work.

(Just to be clear, I have no particular brand loyalty to GPD; they're just the only player in town for high-end netbooks/UMPCs at the moment.)

The Minibook X is obviously targeted at the netbook form factor in the traditional sense, i.e. small and cheap. If you're like me and appreciate the netbook/UMPC form factors (for travel purposes in my case) but also need better specs to actually get any work done -- and you're willing to fork out a bit more to get that -- I would recommend looking at GPD's Pocket and MicroPC series. I own both a Pocket 4 and MicroPC 2 with Linux on them, and I'm quite satisfied. The only issue I've noticed is the same screen rotation quirk described here, for which the same workarounds apply.

I've experienced multiple instances where (so I heard; I don't use Windows) a Windows Update completely broke a game on Windows for everyone, but Wine/Proton kept running it just fine. So we're already there in some sense.

No shellcode decoding

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.

Binary Ninja deserves a mention in these threads: https://binary.ninja

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.

It sounds like you expected 1.0 stability from a language that isn't 1.0.

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.

Just on this point:

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.

You still need a custom distro for Raspberry Pi for example.

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.

I'm fairly sure I recall Fedora folks signaling that they intend to move to RVA23 as soon as hardware becomes generally available.

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.

Most people would be better off waiting for the multiple RVA23 boards that are supposed to come out this year, at least if they don't want to be stuck running custom vendor distros. "RVA23 except V" at this price point and at this point in time is a pretty bad value proposition.

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?).

Our CI workflow literally just invokes a plain old shell script (which is runnable outside CI). We really don't need an overcomplicated professional CI/CD solution.

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.

The reason they move to a lesser known Git provider sounds more like a marketing stunt.

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.

Worth noting that LLVM has AVR and MSP430 backends, so there's no particular resistance to 8-bit/16-bit targets.

Hug of death followed by a DDoS. At the time of me writing this, it loads instantly again.

Go's support for NetBSD has been a big boon to the more casual NetBSD user who isn't going to maintain a port. It means a random Go open-source project you use probably works on NetBSD already, or if it doesn't, it can be fixed upstream. Maybe Zig could play a similar role.

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

As I pointed out in a different comment, even IBM have to maintain a GitHub Actions runner fork with s390x support because upstream just cannot even be bothered to accept the relevant patches: https://github.com/uweigand/runner

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.

obscure OS not being supported

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 much vague outrage over nothing.

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 always have the option of exiting Codeberg to a self-hosted Forgejo instance if that should become necessary for some reason. (Not that I expect it will, considering Codeberg is a non-profit.)

We do self-host all our CI machines.