Just one question: any plans to promote APIs like PyUnstable_EnableTryIncRef() and PyUnstable_TryIncRef() into the limited API? So far we have found that these APIs are necessary to implement the weak-valued caches we've always used in the past: https://github.com/protocolbuffers/protobuf/blob/6559a9f9622...

Instead of "verb object" (eg. delete word or "dw"), it is "object verb" (eg. word delete, or "wd").

In particular, it seems to obsolete "visual mode" from vim (which I use often), because you're essentially always in visual mode. You always get to see a selection before you perform an action. Or at least that's what I understand, I haven't tried it yet.

You're talking to someone who spent a month in college installing every free OS I could get my hands on (including the BSDs). I find alternate operating systems interesting, but haven't played with them much lately. I compare other free Unixes to Linux because I use Linux every day and it's what I know.

It's interesting to think of hypothetical scenarios where an alternative to Linux might be more compelling to me for some reason (eg. is OpenBSD objectively more hardened than Linux? Is NetBSD objectively more portable? etc.)

My thought here is to proactively verify that LLVM elided the automatic bounds checks in places where you believe that your explicit checks should be sufficient.

That was a key part of my article on "No-Panic Rust": https://blog.reverberate.org/2025/02/03/no-panic-rust.html ("A Dance With The Optimizer")

1. It's not reasonable to expect the application layer to carefully partition its work into "I/O heavy" and "CPU heavy" parts.

2. It's not reasonable to queue up an arbitrary amount of work without back-pressure.

I haven't used Tokio much, but if it falls prey to these pitfalls, it would make me pause before adopting it.

I think there are probably ways of using Rust async that don't fall prey to these. Maybe not so much with network servers (I haven't written that many of those), but models where you are evaluating a graph and have more control over how new work is added to the system.

This is not a compelling sales pitch. The point of using a memory-safe language is not needing to put in extra work to avoid use-after-free or out-of-bounds memory access.

It would have been more reassuring to hear that Zig has its own memory safety story that should also be able to prevent most of the same bugs. But instead the answer is "work harder for the same result."

When Zig was first created, Rust looked genuinely harder to use because the borrow checker is so demanding and its errors sometimes so hard to reason about and fix. It made Zig look much simpler and easier by comparison. But now, LLMs are very good at writing Rust. I've been writing Rust using LLMs for weeks and haven't thought about the borrow checker once.

AI made Rust tractable without heroic effort, and in doing so eroded one of Zig's major advantages.

The point about compile times is taken though. Rust is definitely slow to compile, easier to believe it's slower than Zig.

Academics could broaden their horizons and consider the possibility that there are multiple perspectives on egalitarianism, and that the public that funds them is quite split on the issue. If Science is really the priority, it should be easy to stay neutral on unrelated contentious social issues. But I guess it's more fun to preach and condescend to people who disagree, and then complain when those people don't want to fund your enterprise anymore.

It happens indirectly all the time. As of 2025, despite all the funding cuts, the AAAS is still publishing its yearly DEI report, now rebranded as an "Inclusivity for Excellence Report", but containing all of the same stuff: an effort to collect and publish as much demographic data as possible, and a stated goal of getting all the numbers to go in the "right" direction. These practices are too ingrained and sacrosanct at this point to let a mere funding crisis throw them off course.

Proponents of these policies want to have it both ways; they're at one moment just this small thing that nobody should be bothered by, but in the next moment a nonnegotiable bedrock principle that they are unwilling to stop doing, even under threat of losing funding.

When there is too great a difference in ability in a single classroom, teachers struggle to serve everyone's needs. I don't believe anyone is well-served by this.

I agree that what is toxic to one person is not toxic to another, but think that this is largely because many people enjoy seeing their perceived enemies attacked. In other words, it comes down to a viewpoint bias: attacking my group/viewpoint is toxic, while attacking other groups/viewpoints is good and noble.

My ideal is that a de-snarkifier would be strongly instructed to be viewpoint neutral; to filter based on whether the comment is being respectful, without regard to the views being expressed.

My idea would backfire if other people program their filter to reinforce their own biases by favoring content that they agree with and creating or amplifying personal attacks on their perceived enemies. That would be unfortunate, but ultimately we can only control what we do; each person gets to make their own decision.

I want the option to engage with the substance of new developments in the world, technology, etc. without the drama. I don't want to be drawn into the drama of strangers (who could, for all I know, just be bots or ragebaiting AIs).

If I want drama, there's plenty of it on TV, or I could talk to my friends about what is going on with people I actually know.

The anti-pattern, in my mind, is logging on to engage with substantive content and to be inadvertently drawn into flamewars with strangers.

Social media can be intellectually stimulating and educational, but it's also easy to get sucked into ideological sniping and flamewars, even if you didn't go looking for it. The emotional and intellectual energy spent flaming strangers on the Internet is a complete waste of human capital.

With an API like this, I assume you could have a browser extension that could de-snarkify content before showing it to you. You could ask the LLM to preserve all factual content from the post, but to de-claw any aggressive or snarky language. If you really wanted to have fun, you could ask it to turn anything written in an aggressive tone into something that sounds absurd or incompetent, so that the more aggressive the post, the more it would make the author look silly.

This could have a double benefit. For the reader, it insulates them from the personal attacks of random strangers on the Internet. Don't get me wrong, there is a time and a place for real, charged arguments about important issues that affect us all. But there is little to be gained from having those fights with strangers; on the contrary, I think it poisons the body politic when strangers are screaming at each other.

For the writer, it takes away any incentive to be snarky or rude. If other people filter their content this way, there's no point in trying to be mean to them, and no "race to the bottom" for who can be more nasty.

When Gillian Welch wrote "Everything is Free" in 2001, she wasn't complaining about the record companies, she was complaining about Napster.

> Q: Do you remember where you were when you wrote “Everything is Free”?

> A: I do. I remember exactly where I was and what was going on. It was when Napster was starting to decimate the traditional recording industry dynamic, the viability of making your livelihood [from] your art.

--Gillian Welch, 2018 (https://www.rollingstone.com/music/music-features/gillian-we...)