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.

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.

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!