Recently had to develop a Python project, the tests took at least ten seconds to start each single time. This is while I made over a hundred tests for my module and re-ran them after every change.

Python is dog slow, but if your tests are taking 10 seconds to start (not even run!), then something is catastrophically wrong with your setup. For comparison, for one of my projects, it takes a total of 12 seconds to run nox on a clean slate, which involves setting up venvs for five major versions of Python, installing the package and its dependencies in each, and finally running the 1500 test test-suite five times

What about the fact that runtime startup alone auto-disqualifies python for all short-lived process use-cases?

While Python's start-up time is a lot slower than a corresponding compiled program, in most cases it's not slow enough to matter even if the process itself is short-lived:

$ hyperfine 'python3 -c "pass"'
Benchmark 1: python3 -c "pass" (412 runs)
                mean     ±       σ          min     …     max
  Wall Time      7.1 ms  ±     0.2 ms       6.7 ms  …     8.4 ms
  Memory         9.4 MiB ±     0.1 MiB      9.1 MiB …     9.5 MiB

If you are running a small program so often that this kind of start-up time matters, then the loop should probably already be implemented in the program itself. In line with the article's thesis

At this point the people complaining about Rust at every opportunity have become more annoying than the "rewrite it in Rust" people ever were

Betteridge's law of headlines:

Any headline that ends in a question mark can be answered by the word no

It can't be quite that bad; they've been shipping the rust version of Bun with Claude Code since v2.1.181 (released June 18th), and I haven't seen an outcry over all related functionality breaking

Always take these stories with a grain of salt.

For example, while the article claims that "we saw Denmark's government move from Windows to Linux back in 2025", the reality is that it was just one department and they didn't even move to Linux. They merely started a pilot project to see if they could move from Office 365 to Collabora: https://www.digmin.dk/digitalisering/nyheder/nyhedsarkiv/2025/jun/digitaliseringsministeriet-saetter-gang-i-pilotprojekt-om-digital-suveraenitet

The article is about an internal kernel API: They can easily rename those, since they are not exposed to user-space.

But you seem to be talking about the kill command and/or the kill function, that are part of the POSIX and C standards, respectively. Renaming either would break a shit-ton of code, unless you merely aliased them. And while I agree that kill is a poor name, adding non-standard aliases doesn't really offer much benefit

I set the timestamps of my music to its original release date, so that I can sort it chronologically... OK, I don't actually do that, but now I'm tempted

It’s probably easier to strip down GRUB, than it is to resurrect and add missing features to a project that has been dead for 10+ years

I can't believe that Rust developers would call POSIX functions to interact with the operating system! The audacity!

I also saw a 4.5 second boot time speedup from installing mine. I have NO IDEA how, but it’s happened.

If I saw a speedup that I didn’t understand, then I’d worry that I had accidentally broken something. It’s easy to get speedups by not doing things correctly

These are all very useful things to know about, but besides maybe the difference between stack and heap, they are not things you need to learn about before getting starting with Rust.

So if you actually do want to learn Rust, then that's your next rabbit hole

This is probably not worth losing sleep over. OpenAI are not the only Platinum Member, nor the biggest contributor to the Rust Foundation. Microsoft and Google have both contributed at least $1 million each, going by previous press releases. See here for a list of the foundation members

What do you mean, he “admitted” that?

It’s quite literally the first thing he wrote in his pull request to systemd:

Stores the user's birth date for age verification, as required by recent laws in California (AB-1043), Colorado (SB26-051), Brazil (Lei 15.211/2025), etc.

And the second paragraph of his pull request to arch:

Recent age verification laws in California (AB-1043), Colorado (SB26-051), Brazil (Lei 15.211/2025), etc. require platforms to verify user age. Collecting birth date at install time ensures Arch Linux is compliant with these regulations.

Hopefully nobody tells the corpos that they can just use BSD if they want a MIT licensed kernel and user-land

You didn't expect them to use the standard low-level, cross-platform API to build cross-platform coreutils?

Other git hosts are also getting scraped, and have had to implement counters because of it. For example, this is the kind of thing Codeberg shows crawlers. I've even seen people who self-host complaining about getting overloaded because of bots scraping their forge

Banning "AI" is too broad and too shortsighted.

They haven't done that. The actual terms are

You must not share projects that mostly consist of code written by "generative AI"-tools (including services such as Claude, OpenAI Codex). Such projects having an unclear copyright status (see requirements § 2 (1) 1 and § 2 (1) 3) and furthermore have little safeguards to ensure that they do not include harmful code (c.f. § 2 (1) 5).

See also their blog post, where they specifically mentions experiments as "tolerated":

Side projects and experiments with little resource usage

I prefer the classic Bool:

enum Bool 
{ 
    True, 
    False, 
    FileNotFound 
};

This looks like a colossally bad idea:

  if (!strcmp(platform, "windows") && !isSpecificPlatform) {
    debugLog("Falling back to rm -rf", 2);
    debugLog(strfmt("rm -rf exited with code %d",system(strfmt("rm -rf %s", path))), 3);
  }

In addition,

However, their even though their client doesn’t allow vibe coding, it is still written in Python, which itself takes ai contributions.

Per the Makefile, this project is built using GCC. GCC itself accepts AI contributions, provided that the code is "legally insignificant" (meaning less than around 15 lines of code) or is part of test cases: https://gcc.gnu.org/ai-policy.html