haberman

It was a sincere question and I found your comment quite off-putting.

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.)

I often wonder what the current status is of the BSDs (FreeBSD, OpenBSD, NetBSD). Who uses them, who works on them, what is their motivation for doing so? How do they compare to Linux these days, in terms of size, feature set, security hardening, etc? Is their usage/development happening at a relatively constant level, or is it growing/shrinking?

I see two solid points here:

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.

> There's a dichotomy being presented here where you have to either choose a "style guide" or a programming language feature in order to avoid bugs. The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it. You're not giving TigerBeetle nearly enough credit. Quite simply they put in the time to find and eliminate the bugs, they make an effort to maintain a healthy relationship with ZSF, and Bun did not do that.

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.

I’ve always found it especially confusing that energy has this quadratic relationship with speed, whereas momentum is linear in the speed.

The French, who have "égalité" in their national motto, prohibit the kind of demographic tracking and reporting that US Progressives consider core to their project. Do you think the French don't care about egalitarianism? No, they just have a different concept of what that means. Just like many Americans.

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.

I think you can easily turn this around: scientists who are only willing to do science if it involves preferential treatment, DEI statements, and other practices that half of the country despises are saying that it's better to do no science at all than to set those divisive practices aside and just do science.

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.

If this works I wonder why GOG doesn’t do it automatically.

I am not convinced that separating students by ability harms anybody's academic performance. I think it's a false premise that a parent who wants their kid in advanced classes (or advanced schools) is behaving "antisocially."

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'm inclined to think that this will actually decrease the power of echo chambers. Echo chambers become that way by policing dissent, either through moderation or through aggressive attacks on dissenters. A de-snarkifier would de-fang the latter.

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.