tczMUFlmoNk

Some projects, like CPython, collect changelog entries as individual files with random names in a dedicated directory. Then, a script assembles the changelog at release time. I always thought this was a nice and elegant solution: in some sense, a changelog is a list with no special merge handling, but a directory is a list (of files) that does have special merge handling, so you just use that as your substrate.

I don't disagree with your general thesis, but I don't think it's right to say that defining behaviors like dereferencing a null would require a null check before every dereference. For example, Java defines the behavior of dereferencing null—it throws a `NullPointerException`. My understanding is that JVMs implement this by (a) representing Java `null` references as the zero pointer, (b) mapping the zero page with write permission disabled, so that accesses are guaranteed to segfault, and (c) trapping `SIGSEGV` to translate that back into a Java exception.

(Here's a link with a bit more detail: https://courses.cs.vt.edu/cs3214/spring2026/questions/catchi...)

So, while it's accurate to say that inserting null checks before every dereference is one way that you could implement this to make it well-defined, that is not the only way. We have lots of clever tricks to solve problems more efficiently than may seem possible at first glance—Fil-C is a bit of a modern marvel in that regard!

Since "N nines" for positive integers N denotes an uptime of 1 – 10^(–N), I think it's fair to analytically continue that formula, and say that 9% availability corresponds to 0.041 nines!

This is true as stated. However, it is important context that the time bomb was originally introduced in Trump's signature Tax Cuts and Jobs Act in his first term. So, yes, Trump's OBBBA fixed it, but Trump's TCJA caused it in the first place, too.

> As for the detractors, from the first generics proposal this was called out as a "not now", not never.

What? The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods". There is also some similar discussion of the original generics proposal, with language like "then it's much less clear why we need methods at all". (I'm omitting some context, but I don't feel that it changes the meaning.) Those feel much closer to "never" than "not now".)

The post is also subtitled "A change of view".

The converse and inverse are logically equivalent by contraposition, so it doesn't really matter which one you use. If you think through it, you can see that "if you're the product, you're not paying" is equivalent to "if you're paying, you're not the product".

I might guess that GP is referring not to interface ergonomics (for which a struct is a perfectly satisfactory solution, as you describe), but to implementation efficiency. A pointer is one word. A slice / string view is two words: a length and a pointer. A pointer to a slice is one word, but requires an additional indirection. I personally agree that slices are probably the best all-around choice, but taking double the memory (and incurring double the register pressure, etc.) is a trade-off that's fair to mention.

When we're talking scales like 10^-23, "one" and "one sixth" are comparable enough to warrant an "approximately".

This is what I was thinking, too. Without some kind of linearity, `connect` et al. don't give the claimed guarantees if you can just reuse the old socket handle. Especially if it's aliased in a list or something. I was surprised to see this not mentioned at all in the section specifically dedicated to double-close prevention.

Likewise, with implicit weakening, nothing stops you from dropping the socket without closing it.

> Even with only about 1 in 1000 users enabling telemetry

How do you know the number/proportion of users who run without telemetry enabled, since by definition you're not collecting their data?

(Not imputing any malice, genuinely curious.)

It can mean either. "Suspicious behavior" doesn't mean that the behavior thinks that you've done something wrong.

"She's suspicious" can mean either that I suspect her intentions or that she suspects someone else's intentions.

This is effectively what happened with the BotGhost vulnerability a few months back:

https://news.ycombinator.com/item?id=44359619

Red/green has no inherent semantics. It has the semantics that you assign it. If you choose to assign it meaning that disenfranchises 8% of men using your system, that's your choice, but it is not a good one.

The article explains why they want to avoid this option:

> Starting at version 14, PostgreSQL supports generated columns - these are columns that are automatically populated with an expression when we insert the row. Sounds exactly like what we need but there is a caveat - the result of the expression is materialized - this means additional storage, which is what we were trying to save in the first place!

> I don’t see your joke as being in any way harmful towards Sanjay aside from potential knock on effects of Jeff Dean being more popular

I mean… yeah. When two people are peers and comparably well regarded, and one is elevated above the other and enjoys increased popularity, familiarity, and respect, and the elevation is because that person's name comes from a culture that is more aligned with the dominant culture and easier for them to engage with… that is a pretty textbook example of systemic racism.

I'm not at all saying this to demonize Kenton. We can make mistakes and reflect on them later, and that's laudable. But it is important to recognize these systems for what they are, so that we can notice them when they happen all around us every day.

Maybe we could put a wind turbine on the boat, generate electrical power, and use that to power an onboard motor!

Rob Pike retired from Google in 2021.

Ng, Le, Li, Lu, Wu, Xu, Xi, Fu… come to mind immediately for last names.

For first names… Jo, Ty, Al, maybe?

You may wish to search for "readability at Google". Here is one article:

https://www.moderndescartes.com/essays/readability/

(I have not read this article closely, but it is about the right concept, so I provide it as a starting point since "readability" writ large can be an ambiguous term.)

> what about situations where you might have two variables closely related that need to be locked as a pair whenever accessed.

This fits quite naturally in Rust. You can let your mutex own the pair: locking a `Mutex<(u32, u32)>` gives you a guard that lets you access both elements of the pair. Very often this will be a named `Mutex<MyStruct>` instead, but a tuple works just as well.

Umm, actually, it's specifically a coproduct of functional programming. ;-)

https://en.wikipedia.org/wiki/Coproduct

I have usually heard it called "A–AB–B migrations". As in, you support version A, then you support both version A and version B, then you support just version B.

The rest of the sequencing details follow from this idea.

College athlete Lia Smith died by suicide last week after years of targeted harassment and attacks from the people we're talking about. At some point, when the institutions of power do everything they can to demonize your existence, strip you of your accomplishments, and vilify you publicly—across millions of people nationwide—it doesn't matter whether you call it murder or not. The deaths rack up all the same.

Sure. If T is a zero sized type, then chan T should just be an atomic int.

I am not sure how much this improves code readability in practice—I see chan struct{} frequently, but I cannot recall ever having seen chan T for a zero-sized T other than struct{}.

Thanks for explaining!

The term is correct. Grammatically, we would say, "I love vacuous truths", or, "I love vacuously true statements". (To my ear the second version sounds very slightly more appropriate, because in mathematics "vacuously true" is a bit of a set phrase, but both are fine.)

> public key of a wallet (present on any outgoing transaction in the ledger)

Genuine question: is this true? I only know a little bit about Bitcoin, but I thought there was a notion of an "extended public key" that's not exposed to the ledger, where each individual public key on the ledger is only used once, or something like that.

I'm not at all confident in my understanding, so I'd love if you or someone else knowledgeable could help fill in the gaps.

If you have a buffered channel with 100 "true"s in it, you're using 100 bytes.

If you have a buffered channel with 100 "struct{}{}"s in it, you only need to store the length, since the element type is zero-sized.

In fairness, he does say, "guess I was wrong about that" in this piece:

> I was wrong repeatedly in the past decade when I speculated that you can't ship renewable electricity around like gasoline, and that it would mostly be tropical/equatorial nations who benefited from it.