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.
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.
From my understanding:
Peak time (non-promo): UTC 12:00–18:00 / KST (UTC+9): 21:00–03:00
Off-peak time (promo): UTC 18:00–12:00 / KST (UTC+9): 03:00–21:00
I guess I’ll need to do more coding during the daytime.
Atari? I never expected to see that ancient name again. If I remember correctly, I've been playing OpenTTD for more than a decade without the original TTD assets, and I usually build it from source, so this change won’t really affect me. Still, it feels a bit strange (even if it may be somewhat legitimate) to see Atari suddenly asserting rights over it.
The strength—and also the weakness—lies in how WASM is consumed in the browser. During instantiation, JavaScript engines validate the module and reject it if it uses unsupported instructions or features. In practice, due to browser compatibility differences, WASM modules often need to be built in multiple variants, such as a baseline version, a SIMD version, a SIMD+threads version, and so on. This is a significant pain compared to native binaries, which can rely on runtime feature detection and dynamic dispatch.
Before modern standardization, maintaining calendars and clocks was typically the responsibility of states or similar authorities, often guided by astronomers. Now it seems that international organizations are effectively following the early UNIX/POSIX model, and astronomers no longer have the same authority over timekeeping.
Yuck. I’ve already noticed compilation times increasing from C++17 to C++20, and this feature makes it much worse. I guess I’ll need to audit any reflection usage in third-party dependencies.
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.