In this post, I want to make two arguments:

1. That the borrowchecker causes serious ergonomic problems for Rust.

2. That the role of the borrowchecker in Rust's safety is overstated.

Perversely, because Rust's lifetime riddles are challenging, they are sort of fun. I believe that partly explains why so many people don't seem to mind them. Instead of thinking about how to write my code to solve the scientific problems I'm being paid to solve, I have to think about how to write it to please the borrowchecker. The latter is usually more tractable, limited in scope, have clearer requirements and is more 'puzzle-like'. In that sense, Rust enables escapism: When writing Rust, you get to solve lots of 'problems' - not real problems, mind you, but fun problems.

def ascii_safe(x: int) -> bool:
    """True if all four bytes have high bit clear."""
    return all(((x >> (8 * i)) & 0x80) == 0 for i in range(4))

def ascii_safe(x: int) -> bool
    return x & 0x80808080 == 0

jj крута
Посидел я на jj где-то месяц, и... это офигенно.

Т.е. у меня по большей части не обычный "гит воркфлоу", где делаешь фичу, мержишь, делаешь новую, а эдакий стейт "тещу 20 фичей какая заработает"
И jj для этого идеален

<...> I decided someone needed to try to create a Postgres configuration optimized to process queries as slowly as possible. Why? I am not sure, <...>

I can’t make this too easy. This is a Postgres tuning challenge, not a throttle-your-CPU-to-one-megahertz-and-delete-indexes challenge, so all changes must be on parameters in postgresql.conf. Additionally, the database will still need to have the capability to process at least one transaction within a reasonable amount of time—it would be too simple just to grind Postgres to a halt.

What do all three of these bugs have in common? In every case, an invariant was violated thanks to multiple aliased references to the same value.

Invariants are essential to large scale programming, because it is impossible to hold the entire state of a system in your head at once. <...>

However, code inevitably needs to temporarily violate an invariant while performing updates. The problem comes when there are multiple references to the relevant data, and another reference observes this temporarily violated invariant.

The received wisdom suggests that Unix’s unusual combination of fork() and exec() for process creation was an inspired design. In this paper, we argue that fork was a clever hack for machines and programs of the 1970s that has long outlived its usefulness and is now a liability. We catalog the ways in which fork is a terrible abstraction for the modern programmer to use, describe how it compromises OS implementations, and propose alternatives.

As the designers and implementers of operating systems, we should acknowledge that fork’s continued existence as a first-class OS primitive holds back systems research, and deprecate it. As educators, we should teach fork as a historical artifact, and not the first process creation mechanism students encounter.