Yes of course life insurance and pension funds are going to buy this debt. This is the highest quality debt that's out there. If you don't want life insurance and pension funds to buy debt from big tech companies because you believe it's too risky, then you believe that bonds are just too risky in general.
OK, wait a minute. Elsewhere in this discussion, people are saying that only a few of these AI companies are going to survive. For stocks, that can still be a reasonable investment - low odds, but still a positive expectation value - but for bonds, it's terrible. You're paying me single-digit interest when there's only a 20% chance that you live long enough to give me my principle back? Get outta here. Literally nobody should be investing in such bonds.
FWIW, a firm can go bankrupt and the stocks be worth zero with the bond holders being paid 100%. In fact, that's sort of the goal and "ideal" scenario (ideal given bankruptcy, of course, which in turn is not ideal).
In the real world, recovery rates for corporate bonds are between 30% to 70% or so, depending on the seniority of the debt and the collateral.
If big tech bonds are a terrible deal for investors at 8%, then Google or OpenAI is getting a screaming deal by raising debt at that rate. Saying nobody should be investing in these bonds is very similar to saying that big tech should raise more debt.
Agree with you on that. I just wanted to point out that Big Tech debt being a bad purchase for things like pension funds means its a good deal for big tech. Everyone else in the thread seems very negative on big tech debt for some reason. You can't have it both ways.
It was never the intent. What we are seeing is the methodology that Peter Thiel (hello, ycombinator) described in his book Zero to One [0]: "Competition is for losers"
Remember that bug with Intel Skylakes [0]?
When an application used AVX, it slowed down everything else on that node. It was by far not easy to debug why some applications randomly suffered perf hits on a new hardware being rolled out in Azure.
The Intel server CPUs Skylake Server, Cascade Lake and Cooper Lake, which had bad frequency/voltage management are now ancient history and very few of them have been used as workstation CPUs by individual users.
AMD Zen 4 and Zen 5, and also those Intel CPUs with AVX-512 support starting with Ice Lake, behave much better and there is no reason to avoid AVX-512, which has much better energy efficiency than the alternatives.
"Drilling into the original article where Jarred explained the reasoning behind the change, It's pretty clear that under zig the team was doing things by hand that are automatic in rust."
* Claude Fable produced a counterexample to the Jacobian Conjecture
"This is a rare instance where feeding this groundbreaking information into an LLM gives _them_ psychosis. I fed this to claude code and watched it verify the result in 7 different ways to be 100% certain, and it was just flabbergasted. Quite remarkable."
* Ollama: All Aboard Open Models
"A year and still no implementation for such a basic need as offloading MoE layers onto the CPU selectively. On llama.cpp I can get models like Qwen 35BA3B running partially on gpu/cpu with 40t/s on a laptop thanks to --n-cpu-moe but on this VC funded joke it would be simply unusable. I can't quite understand how you make a wrapper so much worse than the code you're ripping out."
* OpenAI reduces Codex Model Context Size from 372k to 272k
"I know a lot of people like to say that compaction makes this moot, but the level of detail you lose across compaction is wildly too much for most things that I do, unfortunately."
* M-Chips: M7 with up to 1.5 TB – and why Apple is skipping the M6
"I hope they put a better connector than TB5 so we can cluster them properly at 1TB/S"
For someone who is not a rust dev, would you mind giving me an example of this:
"Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them."
Aw I feel quite sorry for using the word "demonstrable" while not intending to demonstrate anything, in order to avoid any contributions to the project. I apologize for that.
That being said I've found a case that doesn't do much harm even if it's fixed, and is technically not my contribution. You may take a look at that:
But code is not mathematics, so incorrect code is not worthless, it’s just worth less.
It’ll most likely still do 99% of the things people need it to do, there’ll be a an issue created for that broken 1%, and eventually it’ll be iterated upon and fixed.
Unless you’re working on a security boundary of course, there you should treat it like maths.
> So you haven't understood the distinction or you're letting your feelings for software get the best of you.
Maybe? I'm not sure.
> The proof that there are no (for rust's definition of "no") memory bugs becomes worthless
I still don't think so, the proof that there are no memory bugs is definitely not worthless, since while the whole proof itself is binary (it is either fully correct or not), its effects act more like coverage, and the more of it that happens to be partially correct, the better.
I think cve-rs is the perfect example of this. Its very existence proves that the borrow checker is already unsound, and with that, the very foundations of Rust's safety guarantees are currently flawed.
TypeScript is another good example, its type system has been repeatedly proven to be unsound, so it's also flawed.
But so what if it's flawed? Many smaller properties of these proofs still happen to hold, and they might prevent 90%+ of CVEs even as flawed as they are.
reply