I mean, _now_, sure, I'd assume Microsoft Principals should be hired around L4 at Google. But that's just due to a temporary inbalance in the decline of legacy organizations. Give it a few years and it will even back out and msft 64 will be in the middle of L5 range like levels.fyi claims.

This has just as much value as when an LLM claims it won't make a certain mistake again, and for exactly the same reason.

I first became aware of the phenomenon of an enlightened anti-UNIX bundle in ZFS; in particular how it unifies lvm, RAID, and the filesystem. While zfs isn't universally loved, it seems that each hot new filesystem that comes out now adopts this strategy as well.

While this doesn't lead to immediate enlightenment about where the balance is, it does highlight an important aspect to consider: whether the whole is more than the sum of its parts. One way openzfs is more than the sum of its parts is that it closes the RAID write hole. The next step, whether it be stabilized in openzfs or otherwise, is to merge encryption into the stack: The current state of the art is to compose block encryption with zfs on top. But a better solution would be for zfs's object layer to encrypt its blocks itself. Because the blocks are not required to have a particular disk alignment or size, the filesystem can offer authenticated encryption without losing the random-access property, as well as granular keys, thus offering some clear advantages over the UNIXy composition method.

Actually I'm not sure how strong an example ripgrep is by comparison. Could a `find` replacement do the ignore patterns just as well? OTOH, does ripgrep offer better I/O and compute parallelism than a naive xargs/parallel?

Pi coding agent does this by default with all outputs but Claude (all versions tested, including opus 4.6) just completely ignores this capability. Even when the tool output explicitly tells the agent that the full output is saved in a particular file, Claude reruns the command.

In modern C++ (i.e. with smart pointers) something similar is true in that the UB can only occur in code dealing with certain types and functions (e.g. raw pointers), and not other types and functions. It's really the same as rust, just without the compiler support and the explicit unsafe blocks.

I'm confused at what speculative fiction exists from before the 1910s (or thereabouts) which involves FTL? I've no doubt there's a handful of works but this is hardly a plausible explanation for a _recent_ decline in these topics.

As a counter-example to your idea, it's theoretically possible for a type to have a `?Sized` field (at the end), although this idea was never completely fleshed out in the language. A value of such a type could be constructed on the stack.

Now in practice, if you encounter a type with an unsized type parameter, it's probably a smart pointer. It may have an ownership relation to some data which lives on the heap. That may be what you're referring to. But such heuristics are going to be more confusing than helpful for anyone who doesn't understand the basic premise. The location of data in rust is actually quite simple, but sometimes beginners make it more complicated than it really is somehow.

(Btw, same sort of thing occurs with zfs combining raid and filesystem to close the parity raid write hole. Often strictly layered systems with separation of concerns are less than the sum of their parts.)

This drives up price faster than quality though. Also increases latency.

Unfortunately during coding I have found many LLMs like to encode their beliefs and assumptions into comments; and even when they don't, they're unavoidably feeding them into the code. Then future sessions pick up on these.