Yea, the pervasiveness of this analogy is annoying because it's wrong (because a compiler is deterministic and tends to be a single point of trust, rather than trusting a crowdsourced package manager or a fuzzy machine learning model trained on a dubiously-curated sampling of what is often the entire internet), but it's hilarious because it's a bunch of programmers telling on themselves. You can know, at least at a high level of abstraction, what a compiler is doing with some basic googling, and a deeper understanding is a fairly common requirement in computer science education at the undergrad level

Don't get me wrong, I don't think you need or should need a degree to program, but if your standard of what abstractions you should trust is "all of them, it's perfectly fine to use a bunch of random stuff from anywhere that you haven't the first clue how it works or who made it" then I don't trust you to build stuff for me

I think you're mistaken on that. Maybe me and the engineers I know are below average on this but even our combined knowledge of the kinds of things _real_ compilers get up to probably only scratches the surface. Don't get me wrong, I know what compilers do _in principle_. Hell I've even built a toy compiler or two. But the compilers I use for work? I just trust that the know what they're doing.

I'd wager a lot of money that the huge majority of software engineers are not aware of almost any transformations that an optimizing compiler does. Especially after decades of growth in languages where most of the optimization is done in JIT rather than a traditional compilation process.

The big thing here is that the transformations maintain the clearly and rigorously defined semantics such that even if an engineer can't say precisely what code is being emitted, they can say with total confidence what the output of that code will be.

> the huge majority of software engineers are not aware of almost any transformations that an optimizing compiler does

They may not, but they can be. Buy a book like "Engineering a Compiler", familiarize yourself with the Optimization chapters, study some papers and the compiler source code (most are OSS). Optimization techniques are not spell locked in a cave under a mountain waiting for the chosen one.

We can always verify the compiler that way, but it's costly. Instead, we trust the developers just like we trust that the restaurant's chef are not poisoning our food.

They can't! They can fairly safely assume that the binary corresponds correctly to the C++ they've written, but they can't actually claim anything about about the output other than "it compiles".

Not in any great detail. Gold vs ld isn't something I bet most programmers know rigorously, and thats fine! Compilers aren't deterministic, but we don't care because they're deterministic enough. Debian started a reproducible computing project in 2013 and, thirteen years later, we can maybe have that happen if you set everything up juuuuuust right.