Gavin Howard

Slightly off-topic, but TFA links to https://gavinhoward.com/2024/05/what-rust-got-wrong-on-formal-verification/#the-ugly which says:

> But there is an even harder problem: the C10M Problem. Is it possible to use RSC to handle 10 million connections, of which 1 million need some processing every second?

(RSC being restricted structured concurrency.)

IMO the C10M problem requires: a) user-land network stacks or unikernel servers, b) NPROC (or fewer) threads or processes, c) evented, continuation-passing style code in each of those threads or processes.

I've written one such program (though without (a)), a HTTP read-only file server that does (b) and (c) and which supports "tailing" files by doing `GET`s with `Range: bytes=0-` (or some other starting offset, but no ending offset), and it scales to tens of thousands of concurrent clients trivially. To get to millions of clients I would need to use H/3 and QUIC, and also do (a). (That server also supports ETags and conditional requests. Tailing `GET`s end when the file is unlinked or renamed away. Essentially it is a poor person's Kafka.) This program stores state in a per-client data structure and in the form of a pointer to a continuation closure that is `{data structure, handler closure}` that is registered with the event system, and each handler does only non-blocking operations (if you can think of filesystem operations as non-blocking anyways, though one could also use aio).

I bet this works well with RSC if all…

You're like that person in the Adult Swim sketch about Google being a guy, where the person asking "Google" about something gets a million results showing A) and just 1 result showing B), and they decide to take B).

First of all, if you're really arguing that masks affect mental health more than they save lives (https://gavinhoward.com/2020/08/in-science-all-factors-matter/), I don't even know what to say. I'd really want to see the science behind this, but I suspect there isn't any real science. Common sense and knowledge of professions where people use a mask for long periods of time should be enough to debunk this.

Also, this is truly abhorrent:

> Of course, 161,392 people have died. (Oh whoops! It turns out that only 6% of those people died from COVID-19 alone, so it’s really 9,700 deaths)

If my car breaks don't work, I ostensibly die because I'll be crushed when my car falls of a cliff, but the real cause of my death is the fact that the car breaks didn't work.

For the other article, gee, I wonder if the folks behind it have an agenda to push: "Townhall: <<Conservative>> News, Cartoons, Top Stories".

Anyway, do realize that this is a global phenomenon, people aren't out to get your "freedoms" and countries which are far freer than the US have realized that Covid is a real pandemic and treat it using real science, not pseudo-sience peddled by crackpots or even worse, people with a hidden agenda (usually one about making $$$).

I know I won't change your mind, but…

The author makes the best argument for Rust in the linked post[0]

Rust is great for teams because it removes many things that make working on team code dangerous. The items mentioned above are some. I work alone, however, because I like to keep my code in my head and working with people means parts of the code are only in their head. This also means that the bigger the language is, the less space I have in my head for the code. Rust is too big for my small brain, unfortunately. Most code is written in teams and even software with a single author needs a plan for when the maintainer steps down. Besides this I disagree with the author's assertion that Rust is not well suited for them, in fact I think it's strictly better than C because it often obviates the need to keep stuff in your head. Take lifetimes, in C you have to keep track of pointers and their lifetime in your head, and by definition all other maintainers have to do the same, in Rust the compiler does that for you, less to keep in your head. In fact I think the ability offload things from your head to the compiler is one of Rust's great strength. This ties in with compile times too, yes Rust is very slow to compile, but the compiler also does a whole lot more work than the C compiler. Obviously we want rustc to be as fast as possible given the work it's doing, but it will never be as fast as a C or Go compiler.

0: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-in-memory-safety/

> I think most C programmers frustrations with UB stem from knowing that the C standard has fundamental flaws and modern compilers abuse that fact for "optimizations" on UB

Do they actually know that? I don't think so. Let's take [0] for instance (the author is an expreienced C programmer who loves the language and wrote a re-implementation of bc in it):

There seemed to be a lot of misunderstandings; I could not get a handle on what this person thought UB meant. I finally figured it out: this person’s definition of UB was not “the language spec can’t guarantee anything.” Instead, it was “compilers can assume UB does not exist and optimize accordingly.” Wat. Yep. Apparently, that was news to him, even though C implementations have been behaving like that for about 30 years already, and you can read the rest of the post for the "this is evil, we the users must do something about it" take. And the proposed "something" is not "we should instead use a language with actually defined semantics", oh no. It's "use compiler flags to force more reasonable behaviour, hopefully" and "somebody should write boringcc, unfortunately, I am myself a bit too busy for that". Well, despite numerous pleas and several attempts, nobody has managed to write boringcc which is telling of something, I'm just not sure of what exactly. So... I think it is about imprinting: "Oh, it's a wonderful language, well, it would be if it was actually implemented the way I used to think it is…

Username checks out. :D

If I understand correctly, the issue is mutex on file objects at the kernel level. Basically it is a failing of the implementation of the "file" abstraction. Or perhaps a failing of the "file" abstraction itself?

Per Wikipedia [0] (because I had no idea what a TOCTTOU race condition was)

In the context of file system TOCTOU race conditions, the fundamental challenge is ensuring that the file system cannot be changed between two system calls. In 2004, an impossibility result was published, showing that there was no portable, deterministic technique for avoiding TOCTOU race conditions.[9]

Since this impossibility result, libraries for tracking file descriptors and ensuring correctness have been proposed by researchers.

It seems to me that solutions to the problem from inside the "files as an abstraction" space won't solve the problem.

I was curious to see how a different abstraction would avoid this problem. Plan 9 FS appears to have had this issue at one point [1], but notably not because of the FS implementation itself. Rather the problem was caused by the underlying system's executing outside of the P9FS ordered access to a given file (someone please tell me if my understanding is incorrect).

Here's an article that talks about the problems of this (and other) race conditions from the level of abstraction [2].

NOTE: I'm not claiming that P9FS is immune from this sort of attack, I'm only commenting on what I've found.

[0]…

I don't know man, maybe you should remove some of these posts next time you apply:

https://gavinhoward.com/2020/10/the-next-great-project-zion/

(This one jumped out to me in particular.)
https://gavinhoward.com/2022/08/the-nature-of-heaven-what-i-learned-from-my-first-animes/

https://gavinhoward.com/2021/07/the-next-free-nation/
https://gavinhoward.com/2021/06/israel-is-not-an-apartheid-state/
https://gavinhoward.com/2020/07/political-slavery/

These posts you've been making might have more of an influence on your application than your medical history, bro.

edit:

In this post: https://gavinhoward.com/2021/07/the-next-free-nation/

You stated ..."So the United States must die.

But what will rise in its place will be even greater: Zion."

Bro, I would NOT want you flying my plane after reading that.