OskarS

Yes, you're absolutely right, but you're also illustrating the author's broader point a little bit. For someone not very deeply familiar with Nix (the language), that is a very difficult one-liner to parse. You have to be pretty hard-core nix-pilled to understand what that one is doing just reading it straight-on (my NAS is using NixOS, so I've written some amount of Nix). On the other hand, the TypeScript code the author provides is reasonably straight-forward, you don't have to be particularly familiar with either TypeScript or Nix to understand what it is doing.

You're correct in that the article is wrong in saying you can't use a nix repl this way, but I took the broader point of it to be "Nix-the-language gets in the way of the Nix-the-model". Which is something that I personally agree with 100% and I think the article illustrates beautifully.

It's a very lawyerly distinction you're making here that's willfully blind to what's really going on. The common-sense reading "primary, common, local name" is that it should be called the Gulf of Mexico, as that is what it is called in the USA.

If the nutso president of Turkmenistan decided one day that the Caspian Sea's real name was the Turkmen Sea, there's absolutely no way that Google Maps would rename it on their maps. The reason they renamed it in this case is not because "well, the government said so, so we have no choice!". It's (obviously!) done to not piss of Trump, and pissing off Trump would be bad for their business. They can hide behind lawyerly arguing all they want, but that is the real reason.

I agree. The comment is correct in that it sort-of violates the "purity" of std::indirect that it has this pathological in moved-from state, but it's only an issue when directly using moved-from objects, which is something you essentially never do. Exactly what you say, "in practice" this never happens. Throwing the move constructor out because of it would be throwing out the baby with the bathwater.

std::variant has a similar issue with valueless_after_exception, which given the semantics of the language, it has to have. But similarly, this essentially never happens in practice, and I've never encountered a bug with a valueless std::variant.

> Which the version I showed has none of.

No, it has something much worse, it has a memory leak. The nested types inside the union allocate memory, and they don't get destructed when Event gets destructed. Don't do this in modern C++, it's a terrible terrible idea, these kinds of constructs are very hard to get correct manually. Just use std::variant.

Yes, though in modern C++, don't do this, use std::variant instead. It has better type-safety (nothing stops you from writing to one member of the union but reading from another, causing UB) and handles lifetimes much better. Your version leaks, because struct Event wont destruct any of the nested types inside the union, and in the example, they have heap-allocated data (std::strings and the like). In order to that properly with a tagged union, you need to define the destructor of Event yourself (which is not done in your example) and call the correct destructor manually of the active union member.

Tagged unions (especially with resource-managing types) is hard to implement correctly in C++ (and not trivial in C either). Don't do it, use std::variant.

> One in a trillion times.

This is wildly overstating it. Yeah, I agree, they're much less often the right choice compared to a good-ol' growable array, but they have lots of uses in high-performance code and concurrent code, and they're building blocks in lots of other data structures. Like, in a bucket hash-table, the buckets are linked lists, in a LRU cache you interleave a hash table and linked list, std::hive is a linked list of chunks of elements, etc. Anything that has ever had to deal with memory pooling/allocation uses free-lists which are linked lists. And on and on and on.

I remember vividly being so annoyed when they added W to the Swedish alphabet in 2006. The alphabet I learned to recite in first grade is suddenly wrong?! I still don't say it correctly unless I concentrate, if I have to recite the alphabet, I always skip over W.

The argument at the time was that no "native" Swedish words are spelled with a W, so it shouldn't be part of our alphabet. However, but 2006, enough loan-words had been imported to Swedish with W's (like "webben", "the web") and it was in enough brand names (like "Volkswagen") that it should be included.

But I'm still mad about it! This is my tiny ridiculous hill to die on, W should not be part of the Swedish alphabet!

It's interesting reading this, wondering how much C++26 static reflection could improve the ergonomics of a system like this. Like, if you tag the class with a specific attribute, can you have have it generate the Trace() function automatically? Can you have it automatically wrap the other GC classes using the Member<> template? I think implementing the Trace() function might be doable (you'd do it in the GarbageCollected<> base class that uses CRTP, right?), but maybe not wrapping the types, I'm not sure if reflection allows you to modify types of fields in that way.

Fair enough, I don't know the C++ ABI to this extent.

That's what I'm saying, if you have a CoW filesystem, backing up with atomic snapshots is almost certainly fine, SQLite's advice against copying probably doesn't apply to that. But just typing `cp` in a terminal is probably not a good idea if a transaction is active (even if you're on a CoW filesystem, `cp` in experience usually isn't atomic without some flags).

I think it's reasonable for a DB like SQLite to delegate that to the filesystem. There is an overhead for doing it on the DB level, and since SQLite is just a file on the filesystem which, presumably, is serving many other files as well, why would you trust anything else on the filesystem if you don't trust SQLite? Like, your PHP script (or nginx server executable, or whatever) that is calling SQLite, that's not going to be check-summed either. Either you trust your filesystem or you don't, and if you don't, checksum and error correct on the filesystem level.

Though fair enough, it could offer it as an opt-in thing.