alexrp

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

> Forgejo is more busy managing ideals, than creating software.

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.

The selling point is not merely cross-compilation; as pointed out in the other thread, it's the any-to-any cross-compilation for any supported target. With Zig, you get to download the compiler for any supported host target and then build binaries for Linux, macOS, Windows, FreeBSD, and NetBSD. In the near future, I intend to expand that list to include OpenBSD, illumos, and SerenityOS too.

Zig defaults to statically linking musl when targeting Linux, so the output will not be very interesting unless you target dynamic musl, or glibc, or FreeBSD/NetBSD.

Zig supports both linking modes but has a strong preference for static linking - it's the default in most contexts.

For Zig we use QEMU to run our module test suites on a broad range of targets that we don't necessarily have real hardware for: https://github.com/ziglang/zig/blob/50edad37ba745502174e49af...

My desire to work on said projects is intrinsic; no one around me expects me to do so. In fact, quite a few of my projects add no value to broader society and exist only because I found doing them interesting. I don't imagine the surrounding culture valuing the hunting of giraffes would particularly affect this one way or the other. (Except if said culture doesn't have computers, I guess.)

> personally, this has been a very helpful reframing. If I simply can't bring myself to do something, that means not that I am bad and my willpower is bad, it just means that something is materially wrong and I should consider addressing it by doing things that my body will let me do.

To be clear, I don't think I'm "bad" or that I have a moral failing just because I can't bring myself to do some things. (If anything, that sounds like an internalization of some unfortunate cultural norms...) In my case, it's a contradiction: I want to do a thing for intrinsic reasons, but I can't bring myself to do the thing due to insufficient motivation/focus (for lack of a better term). It can be maddening at times.

But if we take a more typical example that many ADHD people struggle with like, say, doing the dishes or cleaning the house... I guess I don't really understand what might be "materially wrong" here, or how doing something else addresses whatever that is or, more to the point, actually gets those chores done...? This sounds a bit hand-wavy to me.

> The question I pose to the “it’s a disease, medicate it” crowd is; is the person maladapted or is the culture maladaptive?

Overwhelmingly the former in my case. I'll have projects that I desperately want to work on for weeks or months, but just can't bring myself to actually get started on without the extra push from Vyvanse.

It would be nice if society could be just a bit more accommodating for people with ADHD, but that would do nothing to fix this problem for me.

That doesn't seem like a good argument for why Zig ought to target MLIR instead of LLVM IR. I think I'd like to see some real-world examples of compilers for general-purpose programming languages using MLIR (ClangIR is still far from complete) before I entertain this particular argument.

As the guy currently handling Zig's LLVM upgrades, I do not see this as an advantage at all. The more IR layers I have to go through to diagnose miscompilations, the more of a miserable experience it becomes. I don't know that I would have the motivation to continue doing the upgrades if I also had to deal with MLIR.

If you need libc, just link libc? It's bizarre to me that you think less of Zig for giving you the choice.

> Since Zig is not internally supported at Microsoft just yet (chain of trust, etc.)

Is there something about Zig in particular that makes this the case, or is it just an internal politics thing?

We're probably going to add support for cross-compiling FreeBSD's libc in the near future (and I imagine the other BSDs as well). From there, I think the only blocker for Tier 1 is getting it built and tested in CI.

Hm, I didn't think to add Haiku to the support table. It's probably Tier 3; the standard library support is minimal, and we don't support cross-compiling its libc. Patches definitely welcome.

I'll start with your last question: It does know the size of objects - this size is passed to the GC when you allocate memory from it. Root ranges (such as the stack, global variables, TLS areas, etc) also all have a static size.

(Not strictly true - some runtimes have dynamically growing stacks, but the GC knows the size regardless.)

Most garbage collectors assume pointers to be aligned on a word boundary; that is on a 4-byte boundary on 32-bit machines and an 8-byte boundary on 64-bit machines. This is a reasonable assumption because accessing pointers that are not word-aligned is extremely slow on most architectures. It does not care how fields that don't contain pointers are aligned because their contents are irrelevant (so this translates to the compiler being able to pack some fields together without worrying about breaking the GC).

So, a conservative GC will simply scan over every word in an object and interpret it as a potential pointer, regardless of what it actually is. So yes - even a double will be considered a pointer.

Sure. This was just meant as an interesting tidbit. On ARM v8, you'll still need the compiler/VM to help you out as far as type precision goes, of course.

This sounds very much like how Erlang does it - each process gets an isolated garbage collected heap and communication between processes happens through message passing.

How lightweight are Racket places? I'm not very familiar with the language, so I don't know if they're really comparable to Erlang processes.

Hey, you may be interested to know that in the upcoming ARM v8's AArch64 mode, the upper 8 bits of all pointers can be used freely for tagged pointers.

See page 11 of: http://board.flatassembler.net/download.php?id=5698

It's an amazingly in-depth and concise book. I fully recommend it!