No, it definitely isn't. Between the radiation, tendency to accumulate in bone, and shedding pyrophoric flakes, it's really not safe to handle.

I'm thinking about starting a very low dose when the pills come out in Europe. That gives an extra year for more data.

For me it's purely about health (well, about 90% about healthj). I'm a marginal case weight-wise, but the overall health impact profile looks spectacular. If a pill seems likely to add a number of healthy years to my lifespan, yes please. But the more data the better.

One thing that held me back was, I'm very averse to addiction, to anything that might have withdrawal symptoms. People report being ravenous and needing to eat all the time when they quit. BUT - the data shows that after one year, people still retain about 25% of their weight loss, and at two years they're about baseline (some above baseline, some below - the "above" people may be due to sarcopenic obesity, in that you put fat back on faster than muscle, and so your metabolism is lower until the muscle comes back). This is very different from when you diet to lose weight and then stop dieting - you're not ravenous at all, you finally have satiation.

But given the weight regain stats, and the general way these work, what I think is going on is: when you lose weight, you've been training yourself for months on how to ignore or alleve your hunger pangs, so when you stop, you're well trained to it. Whereas GLP-1 agonists are just the opposite: you don't even need to think about resisting the temptation to eat, it just comes naturally; you can get pleasure from something, such as a tasty dessert, without feeling the need to eat everything on your plate; pleasure and craving get separated. So people who just suddenly cut off from GLP-1 agonists are "mentally unarmed" for the reversal. The weight-regain stats however suggest that it doesn't leave you long-term disabled in this regard; that you're just back to your old self once you readjust, whatever that old self may have been.

I haven't read these particular studies, but a lot of the fascinating impacts of GLP-1 agonists occur whether the person loses weight or not. For example, the cardiac benefits are massive, like 2/3rds of the scale of benefits of being on statins, and it apparently occurs independent of weight loss.

One of the annoying things about our wetware is that systems aren't isolated; a "part" that gets used for one thing might also be used for half a dozen unrelated things.

Please understand that there is a balance. Taking things to "reduce inflammation" or to "boost the immune system" run counter to each other. Inflammation *is* the reaction of the innate immune system. The immune system defends not just against pathogens, but also cancer. If you shut down the immune system too much, you can shut down cancer surveillance, which I don't need to stress, is a bad thing.

The downside to inflammation is that, yes, it is damaging. Needless inflammation is bad. And, as an added twist, from a personal example: my mother has Sjögren's and MALT lymphoma in the salivary glands. Sjögren's is an autoimmune condition that attacks exocrine glands. In doing so, it triggers a nonstop immune reaction in the salivary glands and the development of lymphoid tissue, with lymphocytes constantly proliferating. This nonstop proliferation runs the risk of - as in my mother's case - developing mutations that lead to lymphoma. So too much of a needless immune reaction can also cause cancer.

The immune system is an extremely complex, with hundreds of known cytokines, each causing various activation / suppression effects in others and having various other interactions with the body. So it's extremely hard to say, if you tweak this one thing, what will be the overall impact in the long term?

These GLP-1 agonists inhibit the NF-kB pathway and downregulate pro-inflammatory cytokines like TNF-a, IL-6, and IL-1. We think that this sort of downregulation is probably in general beneficial, in that in most cases it should not weaken cancer surveilance, and actually can help with certain types of cancers (but still can be harmful to some). Everything is situation dependent, and there's a lot we don't know.

I decided to randomly pick one of your claims to fact check - that beans are "less than 300 calories a pound!" Here's the info I find:

Cooked Bean Variety Calories per 100g Calories per Pound (approx.)
Red Kidney Beans 127 kcal ~576 calories
Black Beans 132 kcal ~600 calories
Navy Beans 140 kcal ~635 calories
Pinto Beans 143 kcal ~649 calories
Chickpeas (Garbanzo) 164 kcal ~744 calories
Great Northern Beans 139 kcal ~630 calories
Lentils (Cooked) 116 kcal ~526 calories

According to FAO, the average person eats 1,88kg (4,1 pounds) of food (wet mass) per day. Thus beans, with an *average* dietary wet mass (not that one can't readily just eat more!) corresponds to 2157-3050 calories per day.

Globally, most hunter-gather tribes get most of their calories from plants, not animals. Meat commonly acts like a multivitamin - while not that much is eaten compared to plant matter, it provides nutrients that are hard to get (or impossible) from plants. My favorite example is that there are tribes that get the vast majority of their calories from sago, with the Yimar/Yimas getting 93% of calories purely from sago alone. BUT they also eat the sago grubs they find while pounding sago. Sago provides the energy, and the other 7% (commonly shrimp and small fish) provide critical protein and nutrients that aren't present in the starchy sago.

GLP-1 isn't a drug at all...

You know what else distributes spike proteins throughout the body in orders of magnitude greater quantities (rather than the barely-measurable quantities you're referring to)? *Getting infected*. And the lower your antibody titres, the more the spike proteins. Also, vaccine spike proteins are mostly disabled. They're double-proline stabilized; while they can still bind with ACE2, they can't retract the way the virus does for cell entry.

You know what causes far more significant long-term antigen persistence? *Infection, particularly without preexisting immunity, such as from vaccination*.

You know what also causes cardiovascular distribution, prolonged antigen production, and immune-mediated injury vastly more often and more seriously than vaccination* *Infection, particularly without preexisting immunity, such as from vaccination*.

Modern diets barely resemble early diets. While hunter-gatherer diets have varied greatly (paleoarctic people eating significantly more meat than average, for example), modern diets compared to the average paleodiet are high meat, high protein, and very low fibre.

If you want an "average caveman diet", you'd be swapping out a lot of the red meat for plant fibre.

Since Windows never supported this unusual 32/64-bit hybrid, it will have no impact on WINE.

It's actually kind of a cool idea, though. To someone like me who grew up on 8-bit and 16-bit architectures and is regularly taken aback at the size of data structures on 64-bit platforms -- 16 bytes just for a pointer and a length? -- being able to cut those down while still being able to run at full speed [*] on modern hardware sounds really useful.

[*] Assuming it's really full speed. I suspect there's some overhead.

Sure, if you want to run a system with hundreds of known vulnerabilities. Better keep it airgapped.

Er, actually, the above is incorrect and was a result of my contrived test example. With the real data structures there is no risk of anyone moving them because the code that creates them returns *only* a &'static mut. Effectively, no stack frame ever has ownership of the structures, so there is no risk of them being moved. This is all pretty obvious, actually, and essentially necessary. If there is no heap then everything is either stack-based or something akin to a global.

I checked and, indeed, trying to "move" the "hashmap" generates code to copy enough stuff onto the stack to blow it. I'm going to look into using Pin to let the compiler know that none of that stuff is moveable. Thanks!

Without doubt, some Trump flunky will sell a hundred kilos to IBM.

Only to find out it's not the business machine people, it's Iranian Boom Makers.

Yeah, so you apparently missed that I have no heap and the "hashmap" isn't actually a hashmap... and it's actually in the same not-really-moveable space as the data it holds. It would be interesting to look into what would happen if I tried to move it; I think the compiler doesn't actually know that it's not moveable and would generate code to copy it to the stack. That would be more expensive than copying the "contained" data item, since it actually owns its lookup tables by value, rather than holding pointers to heap allocated structure.

As I said, your big-system biased intuitions don't really hold here.

Moving something out of a hashmap and then back into it isn't cheap. I mean, both operations are O(1), but that's amortized and hides significant overhead. I think it's well worth returning a &mut to avoid that, even in the common, std case. In the my noalloc case, it's considerably more complicated than that: The referenced memory isn't really moveable (and it's not really a hashmap). In practice, it would be "copy the data to the stack, leaving the original in-place, then make sure to copy the mutated version back to the original location". The stack consumption of that approach would be worrisome.

This is where the big-system biases of some of the Rust community work against it, and what fuels the certainty of C programmers that C is the right language for tiny devices. In C there would be no question -- you'd just look up the data in the map and return a pointer to it. Very efficient, no needless waste of several hundred bytes of precious stack space or any need to find some other memory region to copy it into. You say that "moves in Rust are cheap" but whether that's true is extremely context-dependent, and it's basically always the case that a pointer is even cheaper.

Unfortunately, the risks of the C approach are very well-understood, and my point in the post with which I entered this discussion was that Rust can be just as good for space and cycle-efficient low-level code as C while also providing significant security and safety benefits. Your arguments would seem to undermine my point about Rust's utility, except that your big-system biases are not, in fact, universal in the Rust ecosystem. There are plenty of people who understand the constraints of writing code on a device with 64K total RAM and a 1K stack who are writing Rust code and ensuring that the language is a good fit.