Note that there are quite a few ways that crypto implementations can be insecure even if it's proven to be "correct" (in terms of inputs and outputs). For instance, it may leak information through timing, or by failing to clear sensitive memory due to a compiler optimization.
Let's say hypothetically that the distribution of stock ownership was more even across the population, and variance was largely (but not completely) due to length of time in the workforce. And further, that the stock owned by workers is a large enough block that they effectively have controlling shares at many companies. Maybe I'm talking about a different universe, but please imagine it for a moment.
Would that hypothetical world be kind of like communism in the sense that the workers own the means of production? If not, why not?
"It is our responsibility to chose the right tool for the job."
That perspective doesn't work well for database products, in my opinion. There is a huge pressure for databases to evolve with your business and applications and to adapt to whatever your throw at it.
Swapping out a database product is less like changing tools and more like changing a foundation. You can't do it every time a new problem arises.
That's not to say you can't use a few different products if that makes sense. But that has its complications.
Simon was one of the first people I met in the Postgres community, perhaps in 2007 at the first PGCon that I attended. We've attended many of the same conferences in places around the world, and I've occasionally had the chance to explore those places with him. He was always kind to me and helped me immensely. I was proud to have the chance to co-author a major feature with him. The last time I saw him was this past December.
Part of the theory is that abstract thought enables culture, and culture enables much faster adaptation than genetic evolution. But still far from instant.
So maybe the abstract thought hardware was there for a long time before we got culturally coordinated enough to use it with full effectiveness to organize large groups capable of outcompeting Neanderthals.
I happen to be reading Sapiens right now. The author seems convinced that we genetically developed the ability for abstract thought (which he calls imaginary or fiction), and that allowed us to cooperate much more easily in large numbers. For instance, believing in a particular flag allows you to identify your allies on the battlefield without having ever met them before. The theory goes that other animals, including other hominins, genetically lack the hardware to rally around a flag.
This also led to the notion of a shared culture across many individuals that can adapt much more quickly than genetic evolution.
(Unless I misunderstand, of course.)
The author squarely blames Homo Sapiens for wiping out the other hominins, pointing out how many other large species seemed to go extinct as soon as we arrived someplace new, even long before the Agricultural revolution.
setjmp/longjmp exist in a lot of real world C code, so there is a lot of value in allowing rust to deal with longjmp in a defined way at least in some narrow cases.
And I don't think it's impossible -- it probably requires some special wrappers (perhaps bindgen could generate them?) that would call setjmp before entering the C code. setjmp has its own set of problems, but I don't believe those are impossible to solve, either.
The article addresses this: "However - and this is the big, enormous caveat of this section - this would rely on the compiler effectively implementing some kind of unbreakable firewall, to prevent a type that does not implement Leak from ever getting used with pre-2024 code."
Why do you say they'd have to be splattered over basically all rust code? The post compares them to Send and Sync, and I don't have to use those very frequently (though I don't write a lot of rust code, either).
The Leak trait could be interesting when it comes to C code that calls rust code that calls C code that might longjmp() over the rust code in the middle.
Right now longjmp()ing over rust code is not a great idea for a couple reasons, but because leaks are currently always allowed in rust, it arguably follows the rules at least in some cases (doing so could cause problems, of course).
If the Leak trait were introduced, then skipping destructors would be clearly the wrong thing to do if there are types on the stack that don't implement Leak. That would clearly require some way to either prevent longjmp() from ever jumping over rust code (e.g. always catch it in C code and turn it into a special return code), or find some way to catch the longjmp and turn it into an unwind in rust (e.g. a panic?) and then turn it back into a longjmp to go back into C.
If that's true, then perhaps AIs would come up with something just by looking at existing observations and "summarizing" them.
Far-fetched, but I try to keep an open mind.