mohamedattahri

Nobody's writing Zig because they think they can beat the Rust compiler.

Comparisons to Rust usually stop at memory safety and overlook what no-hidden-control-flow buys you when it's applied consistently across the whole language.

The same mechanism that lets you control allocation (passing an allocator) extends to I/O. For instance, writing Zig, I know exactly when I'm handing control to the kernel and when I'm not. In the vast majority of languages, it's something you'd observe at runtime, whereas in Zig, it's simply the source code you compiled.

So the point of writing Zig over any other language isn't beating the compiler, it's understanding and controlling what your program does at any given moment.

Thanks.

Not using any new features from 1.26, so lowered the requirements for projects lagging behind a bit.

OP here. Sharing this early because I'm trying to gauge if this specific pain point is widespread, or if I'm just scratching a niche itch.

Context: I’ve been working in a regulated monorepo and realized that almost all existing supply chain tools assume you are a large enterprise with dedicated infrastructure.

The gap I found:

Scanners are reactive (they yell at you after the fact).

Artifactory/Nix are heavy (they require rebuilding your workflow or hosting servers).

I wanted something in the middle. The idea is a lightweight CLI that acts as a local proxy to gate npm/cargo/go requests against policies stored directly in git. It forces "lockfile intent" (what the dev wants) to match "security policy" (what the repo allows) before the package hits the host.

The mechanism I'm most interested in feedback on is the enforcement logic: sbom check --policy-from=origin/main

This allows the CLI to judge the "crimes" on your feature branch against the "laws" defined in main. It effectively prevents a developer from un-banning a vulnerable package in the same PR that introduces it.

Does this "local proxy" approach feel like the right middle ground to you, or is the overhead of a proxy too much for a daily driver?

I'm not discounting her founder status. My point is that it's orthogonal to one's ability to run a company. Founders don't automatically make good CEOs. Plenty of founders step aside for professional management, and plenty stay on and struggle.

Questioning whether someone was the right fit for a role isn't an attack on their legitimacy or their earlier contributions, no matter how pivotal they were. Steve Ballmer at Microsoft had a quasi-founder status, and he received the exact same backlash and hate throughout his tenure because he was perceived as someone who "didn't get it".

If the argument is that any skepticism of a female CEO's performance must be sexist, that shuts down legitimate discussion. I'd rather focus on outcomes rather than on trying to divine each other's motives.

Lastly, Your "pause and do better" is exactly what I'm objecting to: framing disagreement as moral failure. Question Baker? Sexist. Disagree with me? You're not doing enough for the cause.

This has nothing to do with the founder status.

Founders don’t face any competition when they get the job at their own companies, and they often have ownership to force it as an outcome if there’s ever a debate.

Baker, to her credit, probably faced brutal competition to get to the top job. It’s not out there to wonder why she was picked, and the answer cannot be because « she was there from the beginning ».

HN tends to like people who have a certain understanding of product and technology. Baker’s legal background probably didn’t help put forward her other skills, hence the questions.

If the argument is based on trends your personally noticed on HN, then I’m afraid there’s not much to discuss.

I can question the qualifications of a person as it relates to a specific position (e.g. CEO), but that doesn't mean I don't respect their past contributions.

I find the accusations of sexism towards anyone who dares question her as excessive as some of the comments that were made towards her.

There’s a long, long list of APIs which are Chromium-only because Apple and/or Firefox rejected them: Bluetooth, Battery Status, etc.

Yep, and the US had a lot more leverage; out of the US translates into no access to US dollars either directly or via a correspondent bank, which essentially means bankruptcy.

That's why I suggested govulncheck; it can keep a database of suspicious packages and issue a clear warning, and it can be locally check that the hash of tagged version you're using locally is the same on GitHub.