r2vcap

Nobody should feel insulted simply because a project decides to port its codebase to another language. It is a technical decision, not a personal attack.

Zig’s response has been a serious mistake. The TypeScript team ported the TypeScript compiler and language service from TypeScript to Go for TypeScript 7.0. Did anyone interpret that as the team insulting TypeScript itself? I certainly did not.

Those problems are partly attributable to Zig itself. If the project accepted AI-assisted contributions, this controversy might never have happened. Completely shutting out one side of the industry and taking a dogmatic position is not helpful, especially for a pre-1.0 language that is still relatively immature.

Now the Zig community is attacking one of the largest and best-known codebases ever built with the language. Anthropic’s motives are clearly promotional, but even so, I would not choose Zig for any project.

From a supply-chain perspective, Cargo is still in the same broad risk category as npm and PyPI: installing packages means trusting externally published code, including code that may execute during build or installation.

Rather than looking for someone to blame - in this case, GitHub - we should focus on constructive ways to harden the ecosystem.

This is frustratingly one-sided writing. Yeah, WebRTC has limitations, but relying on a standard buys you a lot of correctness and reduces long-term engineering cost. The fact that WebRTC is complicated does not mean it is wrong; it means real-time media over the public internet is complicated.

Also, networking is inherently stateful. NAT traversal, jitter buffers, congestion control, packet loss, codec state, encryption, and session routing do not disappear because you put audio over TCP or WebSocket. Pretending otherwise is not architectural clarity. It is just moving the complexity somewhere less visible.

Yeah, GCC’s recent major releases have been remarkably regular, much like Fedora’s spring releases, and their releases seem to fit into the same broader rhythm. Hint? Red Hat.

Just use Fedora :)

As LLMs improve and adoption grows, maintaining a FOSS project is becoming more complex and more expensive in terms of time and manpower. That part is easy to understand.

It is also become a trend that LLM-assisted users are generating more low-quality issues, dubious security reports, and noisy PRs, to the point where keeping the whole stack open source no longer feels worth it. Even if the real reason is monetization rather than security, I can still understand the decision.

I suspect we will see more of this from commercial products built around a FOSS core. The other failure mode is that maintainers stop treating security disclosures as something special and just handle them like ordinary bugs, as with libxml2. In that sense, Chromium moving toward a Rust-based XML library is also an interesting development.

Does the Python ecosystem have anything like pnpm’s minimumReleaseAge setting? Maybe I’m being overly paranoid, but it feels like every internet-facing ecosystem should have something like this.

It feels like many democratic leaders are starting to think the CCP model—mass surveillance of citizens—is the right direction, with growing demands for chat control, facial verification, age verification, and more. Fxxk any politician who thinks they are above the citizens in a democracy.

Interesting idea overall, and I would support doing this if we can.

Some constraints are:

- Non-programmers are not used to working with Git.

- In practice, they (usually PMs or feature designers) need to write their documents somewhere else.

Possible solutions are:

- Make non-programmers use Git as a documentation tool (upgrade your tooling or GTFO).

- Build a two-way sync tool so that programmers and non-programmers can work from the same source.

  - However, in practice, an SSOT (single source of truth) architecture is usually much simpler. Two-way sync tends to be quite difficult, especially across different platforms.