I'm a mathematician too. They're probably speaking from an intuitive grasp of utility.

"I love life on Earth... but I love capitalism more."

Sexy anti-woke task force officer?

It's "revelation," singular. Like trivial pursuit.

I have observed people taking Rust seriously. You need to reexamine your assumptions.

We have an evolved capability to short-circuit decisions with a rapid emotional evaluation. It means as a species we didn't die out early ["that's a lion; I'm a oerson; lions eat people ergo... Agh!" is not a sustainable strategy] - what's amazing is that we can also apply it to elarned abstract things like an aestetic sense about programming languages. Such instincts aren't always perfect, but they're still worth paying attention to. I don't see a reason not to express that in a blog post, but you can replace it with "this is unergonomic and in some cases imprecise" if you prefer.

That seems like quite a lot of booms.

It does rather sound like proposing an immediate 25k hike in house prices, yeah.

Checked exceptions are powerful but misunderstood. Exception types are a useful part of the facade to a module - they express to a caller how it can go wrong even if used correctly.

Runtime exceptions are typically there to express contract-breaking by callers; although as an alternative return mechanism I've seen them used to simplify the inner workings of some frameworks.

I think they get a bad rep because there aren't a ton of good examples of how to use them - even the java classpath had some egregious misuse initially that helped turn people off the key ideas.

Check Crowdstrike's blurb about the 1-10-60 rule.

You can bet that they have a KPI that says they can deliver a patch in under 15m; that can preclude testing.

Although that would have caught it, what happened here is that 40k of nuls got signed and delivered as config. Which means that unparseable config on the path from CnC to ring0 could cause a crash and was never covered by a test.

It's a hell of a miss, even if you're prepared to accept the argument about testing on the critical path.

(There is an argument that in some cases you want security aystems to fail closed; however that's an extreme case - PoS systems don't fall into that - and you want to opt into that explicitly, not due to a test omission.)

...unless it's running software that uses signed 32-bit timestamps, or stores data using that format.

The point about the "millennium bug" was that it was a category of problems that required (hundreds of) thousands of fixes. It didn't matter if your OS was immune, because the OS isn't where the value is.

Incidentally, this kind of passive-aggressive pressure is the kind of thing that might be considered a legitimate security threat, post xz. If you need to vent, vent in private. If "it works for you" but the maintainer is asking legitimate questions about the implementation, consider engaging with that in good faith and evaluating their questions with an open mind.

Casey's video is interesting, but his example is framed as moving from 35 cycles/object to 24 cycles/object being a 1.5x speedup.

Another way to look at this is, it's a 12-cycle speedup per object.

If you're writing a shader or a physics sim this is a massive difference.

If you're building typical business software, it isn't; that 10,000-line monster method does crop up, and it's a maintenance disaster.

I think extracting "clean code principles lead to a 50% cost increase" is a message that needs taking with a degree of context.