Hey, I like checked exceptions too! I honestly think it's one of Javas's best features but it's hindered by the fact that try-catch is so verbose, libraries aren't always sensible about what exceptions they throw, and methods aren't exception-polymorphic for stuff like the Stream API. Which is to say, checked exceptions are a pain but that's the fault of the rest of the language around them and not the checked exceptions per se.

That texture healing looks super nice. Is that something fonts can just do or does it require special editor support?

If you don't need to reuse the collection or access its items out of order, you can also use Iterable which accepts even more inputs like generators.

...What are they actually launching though? I mean I love the payment scheme but I can't get excited over this without an actual good product being sold.

The one case where I prefer video is when I know next to nothing about the topic and the other choice is mediocre to low-quality writing. Most people aren't great technical writers, and it's easy to skip over steps either because the writer assumes too much prior knowledge or simply because it takes effort to put that information in. On the other hand, videos are the opposite where it takes effort to cut stuff out, so you usually get all the steps which is what I need when I don't know anything.

If I have the option of a well-written, step-by-step tutorial though, or if I already know the topic and have a vague idea of what I'm looking for, then text is much better for being able to search/skim/go back and forth at my own pace.

I consider YabaIRyS more of an epithet than a nickname. I can't imagine anyone using it to replace her name like "I wonder what YabaIRyS (IRyS) is doing", only as a description replacing yabai like "Bruh, YabaIRyS (yabai)" in response to something she did/said.

Forgetting Faufau is pretty indefensible. It's been a long time, but that puts it in the same boat as Kronini and Sanana which I did remember.

I wasn't sure if Fuwa-chan and Moco-chan count as nicknames or if they're just how you say their names in Japanese. I guess dropping the last syllable is what makes it a nickname as opposed to just their real name + Japanese honorific?

At a library level, couldn't you have an opaque sum type where the only thing you can do with it is call a match method that requires a function pointer for each possible variant of the sum type? It'd be pretty cursed to use but at least it wouldn't require compiler plugins.

The behavior is defined; the behavior is whatever the processor does when you read memory from address 0.

If that were true, there would be no problem. Unfortunately, what actually happens is that compilers use the undefined behavior as an excuse to mangle your program far beyond what mere variation in processor behavior could cause, in the name of optimization. In the kernel bug, the issue wasn't that the null pointer dereference was undefined per se, the real issue was that the subsequent null check got optimized out because of the previous undefined behavior.

Do you care about modeling the cells? If not, you could represent each row with just a number. When X plays, add 1 to all the rows that include the position they played, and when O plays, subtract 1. If any row reaches +3 or -3, that player wins.

As for rotation/reflection invariance, that seems more like a math problem than a Rust problem.

It's a Substack thing, not added by the author

Ask it a question about basketball. It looks through all documents it can find about basketball...

I get that this is a simplified explanation but want to add that this part can be misleading. The model doesn't contain the original documents and doesn't have internet access to look up the documents (though that can be added as an extra feature, but even then it's used more as a source to show humans than something for the model to learn from on the fly). The actual word associations are all learned during training, and during inference it just uses the stored weights. One implication of this is that the model doesn't know about anything that happened after its training data was collected.

I disagree with the author on operator overloading. They claim that this function in C

float foo(float a, float b) {
	return a+b;
}

is perfectly clear because you know it's doing floating point addition, while this function in Python isn't

def foo(a, b):
	return a + b

because you don't know if it's floating point addition, integer addition, or string concatenation, and what happens if the inputs are different types?

I think that's fundamentally mistaken. You could also ask of the C version if it's doing normalized floating point addition, denormalized floating point addition, infinity addition, or NaN propagation. What happens if you mix different types of floats? And the answer is that it doesn't matter. These are all just aspects of floating point addition. It returns the most sensible result in whatever format is best to hold that value, and you don't need to worry yourself about how floats are stored under the hood.

The same is true of the Python version. It doesn't matter if it's integer addition or floating point addition or string concatenation. Those are just different aspects of the addition operator and it returns the most sensible result in whatever type is best to hold that value.